Wish Items

[hermanm]

Using RC3

1. Hide the LISP globals from Recent Input when an ODCL project is loaded.
Is this possible?

2. Provide a (dcl_unloadproject) function.
Or, correct my (mis)understanding that it is necessary to shut down autoCAD in order to reload a changed ODCDL project.

[Kerry]

... to reload a changed ODCDL project.

When developing you could use the 'reload' flag for that method ..
... just add T to the parameter list.

See attached ..


[attachment deleted by admin]

[BazzaCAD]

Using RC3

2. Provide a (dcl_unloadproject) function.
Or, correct my (mis)understanding that it is necessary to shut down autoCAD in order to reload a changed ODCDL project.

Kerry is right in his suggestion to use the 'T' during development, but an FYI, yes there is a  (dcl_Project_UnLoad  ProjectName [as String]) function already...
Not sure I under stand your first wish...

[Kerry]

I can imagine times when removing loaded projects from memory would be useful.

Sorry, I meant to mention (dcl_Project_UnLoad  ....

[hermanm]

Thnks for the info..
Just what I was looking for.:)

RE: First wish

ACAD context menu (right click menu) Recent Input -> shows odcl callbacks for form controls, which seems undesirable to me.
These function calls do not appear in the command history window (F2), which seems to me more desirable.

[hermanm]

OK, I notice the help says this
(under Additional Functions):

Note that (dcl_loadproject) and (dcl_unloadproject) are deprecated and replaced by (dcl_project_load) and (dcl_project_unload)

In fact:

Command: !dcl_unloadproject
nil

Command: !dcl_loadproject
#<SUBR @072e244c <EXRXSUBR>>

Command: !dcl_project_load
#<SUBR @072e244c <EXRXSUBR>>

Command: !dcl_project_unload
#<SUBR @072e244c <EXRXSUBR>>

So, it might be good to change the function calls in exmple files to reflect the new usage.
Thanks again.

[BazzaCAD]

So, it might be good to change the function calls in exmple files to reflect the new usage.
Thanks again.

Which examples are you referring to?
All the examples use  "_OpendclUtils.lsp" to load the projects & it calls (dcl_PROJECT_LOAD), so I'm a little confused....

[hermanm]

OK, I must be confused also
I used the old function call, but may have picked it up from an old ODC project file.
Been awhile since I messed with this stuff.

Sorry about that.:(

[owenwengerd]

ACAD context menu (right click menu) Recent Input -> shows odcl callbacks for form controls, which seems undesirable to me.

I don't think there's any way to prevent this for modeless dialogs.

[hermanm]

OK
I tried to localize the callback, without success:

Command: ; error: no function definition: C:SLIDE_ONMOUSEDOWN

(I left _ONMOUSEUP global, -> no error msg)

When I expose the callback, the control works as expected.

The help file gives this example:

Here is the same routine with functions nested to eliminate global variables


(defun c:Events       (/ sVariable
                             c:EventHandling_TextBox1_EditChanged                              c:EventHandling_OK_Clicked
                             )
  (defun c:EventHandling_TextBox1_EditChanged (sText /)

Is this supposed to work?

[Kerry]

Herman,
I've had mixed results localising the USBR's defining the Event callbacks.
Generally I've been able to localise them for modal dialogs.

I'd need to see your code and ODCL to comment on your question and observations.

[Kerry]

additionally,
For instance ; C:SLIDE_ONMOUSEDOWN (..) does not seem quite correct.
I assume you've edited the Callback Function Name in the editor from it's original

c:Project1_Form1_SLIDE_OnMouseDown

[owenwengerd]

I tried to localize the callback, without success:

As long as the callback function is defined when the dialog needs to call it, localizing will work fine. Just be aware that when you call (dcl_form-show) to display a modeless form, the form will still be displayed (and need to call its event handlers) *after* the (dcl_form_show function returns. Localizing ab event handler for a modeless dialog will therefore fail, because by the time the dialog calls it, the containing function will have completed and the local functions will have gone out of scope.

The moral of the story is that you can only define local callback functions for modal dialogs.

[hermanm]

Yes, this is a modeless dialog.
Yes, I provided a var name.
here is code fragment:

;;;command to load odcl project & initialize the form
(defun C:ImgBtn ( / );c:Slide_OnMouseDown)
;;;callbacks for image button
;;;OnMouseDown acquires image coordinates to enable swapping slides
;;;and set variable(s) to do something useful based on the selected point
(defun c:Slide_OnMouseDown (nButton nFlags nX nY /)
      (setq  %X (/ nX Width) %Y (/ nY Height))
      (princ (strcat "\n" "X= " (rtos %X 2 2) "\n" "Y= " (rtos %Y 2 2)));diagnostic print
;;need to map the pick point, based on _relative_ coords
      (setq Map# (map_slide %X %Y XMap YMap))
      (display_slide  slide (slide_name Map#) nil)
      (dcl_Control_SetCaption Text1
        (cdr(assoc Map# just_list )))
)
  (if (dcl_Project_Load "ImgBtn.odcl" T);T is reload option
   (progn
    (dcl_Form_Show ImgBtn)
    (dcl_SlideView_Load Slide "A0.sld")

;;---------end fragment----------------

I get it (I think). The C:xxx function which displays the form - i.e., calls (dcl_form_show) - runs to completion, but the (modeless) form is still active after the function which calls it returns, so the form still needs its callbacks.
IOW, what Owen said.

Thanks very much to all for info.:)

[hermanm]

Further comment:

Presumably(?), the callbacks would have to be exposed, if the project was compiled to a separate namespace vlx.
Is this a correct assumption?