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.
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.
David Henderson
dhSoftware - Add-on Macros for DataCAD
dhSoftware - Add-on Macros for DataCAD