Hi,
It seems that MicroStation loads the VBA project connected to the last WorkSet loaded even before any file is opened.
I have a VBA project in WorkSet A that hooks into file open/close events. When I start CONNECT, it remembers the last WorkSpace/WorkSet that was used (in this case WorkSet A) and it is pre-selected in the backstage. If I select some other WorkSpace/WorkSet and open a file the code connected to the file open/close event from WorkSet A is still executed.
This makes it impossible to switch between different WorkSpaces/WorkSets that has VBA-code containing event hooks.
Regards,
Krister
Hi Krister,
I have tested this issue and was able to reproduce it. VBA projects are loaded (and OnProjectLoad subroutines are executed) before a file is selected to open.This enables eventhandler from VBA projects configured for the previous used workset.I will investigate further and will come back as soon as I have more details.
Best regards,Artur
You may also want to check if the same is true for applications loaded by MS_DGNAPPS.
/Krister
Owner consultant at Surell Consulting AB
I have tested to add apps to MS_DGNAPPS on user level (personal.ucf) and workset level (workset CFG file), but I did not notice a problem with changing the workset.Did you experience any issue? If so, on which configuration level did you add apps to MS_DGNAPPS?
No, I have not tested any apps using event hooks. I suppose the issue is that if the app is loaded using the previous workset the hooks remain active even if a new workset is selected before opening a file.
there should not be any issue with apps loaded via configuration variable MS_DGNAPPS. Such apps are loaded after the load process of a drawing file is started.This is different to the VBA engine. The VBA engine is started before the MicroStation Manager (Backstage) is opened. Together with the VBA engine start also all VBA projects listed with MS_VBAAUTOLOADPROJECTS are loaded and subroutines with name OnProjectLoad are executed. After that the Backstage opens and allow the user to change the workset and open a file. Eventhandler are then already started. A workaround could be to check the current workset and remove eventhandler if not matching.Still testing if other workarounds exist as well and will come back with final results.
I don´t think checking for workset will work. When the backstage is loaded the workspace is obviously correct and the code is executed. When selecting a new worksets that workset may or may not have any VBA code and can not uninstall any hooks.
What is the status of this? Any progress?
It´s a real pain to have File Open/Close hooks being active in the wrong workspace.
actually VBA is started before a user manually can switch a workset to avoid VBA projects from a wrong previous used Workset to be active.One possible workaround is to use MicroStation command line switches and select a workset with starting MicroStation.If with this command line switch a change of the workset is executed, this happens before VBA is started.E.g. we have worksets named "worksetA" and "worksetB". To make sure only the VBA Eventhandler from the correct corresponding workset are active, we could start MicroStation like this:
microstation.exe -WS_USTN_WORKSETNAME=WorksetA or microstation.exe -WS_USTN_WORKSETNAME=WorksetB
I will also file a Defect to make sure this issue will be addressed.
I have filed Defect # 1077281 to address this issue with having VBA Eventhandler active in a wrong workset