Topic Title

I am working on a macro that creates quite a lot of objects that need to be freed when the macro terminates (TLists, forms), and I have appropriate logic to do that (either when the macro exits normally or when the aLast Action occurs).

If I press a shorcut key (such as Shift/M to invoke a different macro) then my aLast logic is being called and all is good.
But if I invoke another D4D macro from the top Toolbox menu the new macro appears to be invoked without the aLast action being passed to my running macro (and hence no cleanup takes place). I can predictably crash DataCAD in this way.

Although I believe this is a problem with the way DataCAD invokes the other macro from the Toolbox menu without passing an aLast action to the running macro, it got me to examining the way my macro handled items in memory, and I believe that there is also room for improvement there:

It is well documented that any variables a macro wishes to retain between dispatcher calls should be included in the memory pointed to by the pl parameter to the main function.

A few of the provided sample D4D macros create forms, and none of those form variables are included in the pl^ memory area. That is fine as all the sample macros display the forms modally (so no dispatcher calls can take place whilst the form exists). My macro has forms that remain open between dispatcher calls, but I didn't really think much about this when coding and just used the default form variables in the form units (did not include my form variables in the pl^ memory area). This is not the cause of the DataCAD crash I detail above (I can reproduce that crash even if I call the other macro before any forms have been created), but I am thinking the forms not being in the pl^ memory could potentially cause problems.

My macro appears to work fine and the forms continue to display and function correctly over many dispatcher calls.

I have had a few cases where DataCAD gets into an undending loop of error messages if I invoke QuickShader whilst the macro is displaying a form (QS works fine, but I get the error messages when I return to the macro ..). This has happened probably 3 or 4 times, but I cannot reproduce it predictably (haven't managed to reproduce it at all in the last couple of days). I am thinking this could be a result of my form not being in the pl^ memory area?

I think I need to include any non-modal forms in the pl^ memory area that DataCAD knows about, but if anybody has any observations or suggestions in this regard I would be grateful to hear them (.... moving my form variables is going to require a bit of redesign to avoid circular references).

Thanks to anybody that can provide advice in this regard ....
David H.

[Mark F. Madura]

I mean that I am using a macro (potentially deep into the menus of the Extrude macro I am working on) and then I go to the Toolbox menu at the top of the screen and select a different macro as shown below:

Toolbox Menu.png (21.66 KiB) Viewed 7284 times

Illustration above shows DataCAD 21 (which is what I have my Delphi Debugger set up to invoke), but same thing happens in 22. I first notice this when using the AttributeMngr macro. The crash does not seem to happen with the old Classic DCAL macros which is why I added the sample Show_Form and Hello_World macros to test with (and the crash does occur if I invoke either of those simple macros).

I have now moved all my form variables into the pl^ memory area and DataCAD is still crashing when I do this.
If I am running DataCAD through the debugger it never hits a breakpoint at the ALast logic but I see the exception below, otherwise DataCAD simply exits without warning if I am not debugging.

Debugger Msg.png (10.5 KiB) Viewed 7284 times

[Mark F. Madura]

I can confirm that invoking a hotkey while a macro is running will set the state to aLast, but selecting a macro from the Toolbox pull-down menu or clicking on the Toolbox left-hand menu does not. I'm not sure yet where I can handle this properly, but I'm looking into it.

The condition of running a macro with a non-modal dialog, thus being able to access these menus was not considered previously.

Thanks Mark,

Unfortunately my new macro can display up to 3 non-modal forms and they are fairly central to the macro's design. I don't often use the Toolbox pull-down, so it was just luck (good or bad, I'm not sure) that I stumbled upon this problem.

dh