Robert Bell noted in a recent thread that there is a bug in using the "Most Recently Used" file list to open files. Apparently this happens when SDI = 1 and LISPINIT=1. Though I could not get the bug to appear for me today, (I had my butterfly net out but no luck), I did notice that a reactor application that I had written to manage scale when switching tabs and viewports started having problems. Apparently vlr-command-reactors, perhaps only the :vlr-command-ended reactor, do not disappear when a drawing is opened when SDI=1. Let me say that again for emphasis: :vlr-command-ended reactors seem to have a life of their own beyond the drawing they spawned in. They don't die in SDI=1 unless specifically removed. Since these zombie :vlr-command-ended reactors were still around without their callback functions while the new drawing was loaded, they cluck clucked about their missing callbacks (like chickens with their heads cut off) until the statements in the acaddoc.lsp were processed and the application reloaded. The reactors, in fact, multiplied like rabbits every time a new drawing was opened since, each time the application set up a new reactor for the same events. I added a statement to my application to add an editor reactor to trap the :vlr-begindwgopen event only if SDI=1 and kill the reactors before they became zombies and it worked. Just thought I'd give you reactor folks a heads up. This is probably not a problem if the reactors are separate namespace applications. Regards, Doug ADT3.3/ACAD 2002/WinXP Pro ;;-----------TESTREACT.LSP in local directory ;Test program for bad behavior check: TESTREACT.LSP (setq testreactor (vlr-command-reactor nil '(vlr-commandended . dummy)))) (defun dummy (reactor cmdlist) nil) ;|---Test segment to tame the problem (if (= (getvar "sdi") 1) (progn (vlr-editor-reactor nil '(vlr-begindwgopen . testcleanup))) (defun testcleanup (reactor lst) (vlr-remove reactor) (vlr-remove testreactor)))) ; uncomment out this section to see the problem solved|; ;;Use (vlr-reactors) to see the reactors multiply without the fix. ;;-------------End TESTREACT.LSP ;;--ACADDOC.LSP (in local directory[don't overwrite your existing acaddoc.lsp]) (load "TESTREACT") ;;------------End ACADDOC.LSP
<eeks> I'm sure glad I only use VBA Events... gotta check those out on this problem however. -- R. Robert Bell, MCSE www.AcadX.com | Robert Bell noted in a recent thread that there is a bug | in using the "Most Recently Used" file list to open files. | Apparently this happens when SDI = 1 and LISPINIT=1. | | Though I could not get the bug to appear for me today, | (I had my butterfly net out but no luck), I did notice that | a reactor application that I had written to manage scale when | switching tabs and viewports started having problems. | | Apparently vlr-command-reactors, perhaps only the | :vlr-command-ended reactor, do not disappear when | a drawing is opened when SDI=1. | | Let me say that again for emphasis: :vlr-command-ended | reactors seem to have a life of their own beyond the | drawing they spawned in. They don't die in SDI=1 | unless specifically removed. | | Since these zombie :vlr-command-ended reactors were | still around without their callback functions while the new | drawing was loaded, they cluck clucked about their missing | callbacks (like chickens with their heads cut off) until the | statements in the acaddoc.lsp were processed and the | application reloaded. The reactors, in fact, multiplied like | rabbits every time a new drawing was opened since, | each time the application set up a new reactor for | the same events. | | I added a statement to my application to add an editor | reactor to trap the :vlr-begindwgopen event only if SDI=1 | and kill the reactors before they became zombies and it | worked. | | Just thought I'd give you reactor folks a heads up. This | is probably not a problem if the reactors are separate | namespace applications. | | | Regards, | Doug | ADT3.3/ACAD 2002/WinXP Pro | | | ;;-----------TESTREACT.LSP in local directory | ;Test program for bad behavior check: TESTREACT.LSP | (setq testreactor (vlr-command-reactor nil '(vlr-commandended . dummy)))) | (defun dummy (reactor cmdlist) nil) | | ;|---Test segment to tame the problem | (if (= (getvar "sdi") 1) | (progn | (vlr-editor-reactor nil '(vlr-begindwgopen . testcleanup))) | (defun testcleanup (reactor lst) | (vlr-remove reactor) | (vlr-remove testreactor)))) | ; uncomment out this section to see the problem solved|; | | ;;Use (vlr-reactors) to see the reactors multiply without the fix. | | ;;-------------End TESTREACT.LSP | | ;;--ACADDOC.LSP (in local directory[don't overwrite your existing acaddoc.lsp]) | (load "TESTREACT") | ;;------------End ACADDOC.LSP | |
As the documentation says (somewhere), it's always best to remove all reactors on a drawing close with SDI>0. At some point I found it true and continue to do just that. The worst I run into is a "pure virtual function mumble mumble" error when calling a regular DCL dialog from a close reactor. Though that's a stipulated no-no (the DCL), the function succeeds and the error message never leaves any scars.
Hi John, Trip go well? After I posted, I tinkered around and found the method I'd recommended for avoiding the problem (checking SDI before setting up a removal reactor) was not good either since SDI can be changed during a drawing session. So I went with: (setq cmdreactor (vlr-command-reactor nil '(vlr-commandended . niftycallback)))) (vlr-dwg-reactor nil '(vlr-beginclose . reactorcleanup)))) (defun niftycallback (reactor lst)......) and something like (defun reactorcleanup (reactor lst) (vlr-remove cmdreactor) (vlr-remove reactor)) That works fine. Thanks for the confirmation. Regards, Doug
Since I can't be sure that there are other reactors out there firing on the close event, I should presume to close all the reactors before they have had a chance to fire. Perhaps another reactor from another application needs to do something at close. It would be presumptive of one application to close another application's reactors. The issue is really more complicated than that with separate namespace vlx's and vba reactors that aren't affected by (vlr-remove-xxx).. I reserve (vlr-remove-all) for testing and debugging only.
