Wish Items

Started by hermanm · 2007-07-14 02:30 UTC · 16 replies · SMF topic #16

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.
... 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]
author=hermanm link=topic=16.msg59#msg59 date=1184380244 wrote:
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...
I can imagine times when removing loaded projects from memory would be useful.

Sorry, I meant to mention (dcl_Project_UnLoad  ....
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.
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
#>

Command: !dcl_project_load
#>

Command: !dcl_project_unload
#>

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

author=hermanm link=topic=16.msg66#msg66 date=1184445155 wrote:
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....
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.:(
author=hermanm link=topic=16.msg65#msg65 date=1184437138 wrote:
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.
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?

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.
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


author=hermanm link=topic=16.msg70#msg70 date=1184466567 wrote:
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.
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.:)

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?
From memory ..

Yes Callbacks need to be global ... and

Add (vl-arx-import "Opendcl.xx.arx")
to the head of lisp file

call all control methods something like this
(Odcl_Control_xxxxxxx  (vl-doc-ref ) )


It's been a while since I've done  seperate namespace work .. sorry not more explicit.

Also you need to quote ' the symbol so you will end up with (dcl_Control_xxxxxxx  (vl-doc-ref ') ).

However if you construct the ControlName at runtime (say if you want to populate many edit boxes with data using the same dcl_control functions) - you shouldn't quote it because it gets evaluated, for example :

(dcl_Control_xxx  (vl-doc-ref (read (strcat "" (itoa ct)))) )