"VBA Run" Key-in does not load projects which are found via MS_VBASEARCHDIRECTORIES

Hello everyone, 

I have a kind of strange behaviour with the keyin "VBA RUN [project name]module name.subprocedure". 
The help file says that this keyin is to load and run a vba macro. (So I do not have to have seperate key ins to load and another one to run a macro.)
This works fine when I open a project in the VBA Manager by hand. Even if I uncheck the "loaded" check mark after it has been loaded.

What is strange now:

It does not work with projects which are found on startup via the config variable MS_VBASEARCHDIRECTORIES.
I do not have them set to "loaded" and also not to "load on startup", because I want to keep the memory clean if these macros are not in use. 
If I check the "loaded" check mark on these automatically found VBA macros the key in works fine. 

If I add the automatically found project again by hand, then uncheck the "loaded" and do the key in it works also fine. 

So it only does not work when the projects are found automatically on startup and are not set to loaded and also not to load on startup. 

Has anyone else encountered the same behaviour? Or should the macros set to be "loaded on startup" everytime? 

-------------------------------------------

Currently using:

OpenPlant Modeler - Version: 10.08.00.51

[MicroStation - Version: 10.14.02.01]

Parents
  • Hi,

    do you notice any message in the Message Center when executing these keyins without success?

    By default with creating a new VBA project the project name and file name are identical, but both could be renamed.
    Are there any differences between the filename of the .mvba files in Windows Explorer and the names of the project within the VBA Editor?

    Thanks

    Artur

  • Hi Artur, 

    thanks for the reply and sorry I forgot to add the error message. There is one and it is the following: 

    "VBA interface error: could not find project or project file"

     

    I had the same idea as you, that there may be some difference in the names, but they are all correct and do not differ.

    Especially since they work fine when I "preload" the project by clicking the "load" check mark, without making any changes to the key in. 

    It looks like MS has a problem finding the projects when they have not been loaded prior, but are only shown in the VBA Manager. (Controlled by the MS_VBASEARCH variable and the corresponding folder.)

    Once I have added them by hand (with the open project symbol (yellow folder)) everything works fine, even if I uncheck the loaded check mark. But they do not work if they are only "shown" by the manager via the vbasearch variable. (Sorry if I am using wrong terms, it is kind of difficult to tell what the manager does with the VBAs which are not "loaded" but are shown in the manager at startup by the vbasearch).

    -------------------------------------------

    Currently using:

    OpenPlant Modeler - Version: 10.09.00.74

    [MicroStation - Version: 10.14.02.01]

  • Hi Florian,

    I have tested this in my environment, but was not yet successful. Possibly I there is a detail I am not aware of.
    According the error message it seems to be related to the project name (or filename?), special characters in names like "äöüß" I have tested and may exclude as reason.
    Could you please provide examples of filename, projectname, subroutine.
    Also the structure of the variable MS_VBASEARCHDIRECTORIES.
    Best would be if you also could upload a minimal vba project file to allow us reproducing the issue.

    Thanks,

    Artur 

  • Hi ,

    Do you mind opening MicroStation and running the key-in "show configuration" a.) once for the case where you cannot load the VBA Project then key-in and save the information provided as "Error-Config.txt", then b.) load the VBA successfully and key-in show configuration and save as "Good-Config.txt"; then zip and attach those two files for review?

    Thank you,
    Bob (and Artur)



  • Hello Artur and Robert, 

    thanks for the replies.

    Regarding the structure of the MS_VBASEARCHDIRECTORIES variable:

    It is like in the following picture. Note: The desktop path normally is not there, I just added it for testing here for this thread. 

    Regarding the configuration: 

    I do not want to share the whole configuration because of compliance reasons. But I made a text comparison of the two versions (via word) and they are exactly the same. Kind of what I expected, because the only thing I change is checking the "loaded" in the vba manager. So this has nothing to do with the configuration. 

    I think you may be interested in the vba variables, so I made a cutout of the config of that part: 

    Regarding the names of file, project, module and subroutine: 

    I made a classic "Hello World" mvba to make the test a little easier and to minimize possible error locations. This very simple macro shows the same behaviour as our other ones. The vba run key in only starts the macro when it is checked as loaded. It does not start when this is not checked.

    I made a quick screen capture to demonstrate the behaviour: 

    Maybe the plugin does not work properly, so here is the screen capture to download: 

    ScreenCapture.rar

    Here is the vba which I used, which is located in a folder on my desktop for the purpose of the video: 

    TEST_Hello_World.rar

    -------------------------------------------

    Currently using:

    OpenPlant Modeler - Version: 10.09.00.74

    [MicroStation - Version: 10.14.02.01]

  • Hi Florian,

    thank you for providing these details.
    After some tests I was able to reproduce the issue. 
    It seems to be related to the configuration level to define MS_VBASEARCHDIRECTORIES.
    I have not yet completed all testes to make sure any side effects, but from what I see now is, if I am using a folder to place macros and add this folder to MS_VBASEARCHDIRECTORIES on level workset, workspace or application it worked for me.
    Only if the folder is set on level user (personal.ucf), the project is not found.

    I would ask you to test the same and confirm my findings.

    Best regards,
    Artur 

  • Hi Artur, 

    thank you for the tip. 

    I had the MS_VBASEARCHDIRECTORIES variable set to user in my previous screenshots, because I added a desktop folder for testing.

    Normally is is set on WorkSpace level as shown in the screenshot. 

    But I think we are looking in the right direction. Because I noticed that even if I have the projects set to autoload at startup (via the MS_VBAAUTOLOADPROJECTS) they are not really loaded at startup. Only the checkmark at autoload is checked, not the one of the "loaded" boxes. 

    -------------------------------------------

    Currently using:

    OpenPlant Modeler - Version: 10.09.00.74

    [MicroStation - Version: 10.14.02.01]

  • Hi Florian,

    some more testing provided a better picture of the issue. It is just a missing Backslash ("\") at the end of the path which is causing this problem.
    It is also confusing, that the VBA project manager (open with keyin: macro vba manager open) is listing the project, but the keyin "vba run [project].module.subroutine" is not working.

    I hope you can confirm this?

    Best regards,
    Artur 

    Answer Verified By: Florian S. 

  • Hi Artur, 

    thank you very much. 

    You are absolutely right, adding the slash at the end of the path makes the difference between only showing the projects in the vba manager and being able to run them with vba run key-in. If there is no slash at the end the vba run key-in does not find the project, but if the slash is added in the path it runs as expected. 

    -------------------------------------------

    Currently using:

    OpenPlant Modeler - Version: 10.09.00.74

    [MicroStation - Version: 10.14.02.01]

  • I was able to reproduce the issue. 
    It seems to be related to the configuration definition of MS_VBASEARCHDIRECTORIES.

    Good detective work, Mr Holmes!

    FWIW this Configuration Verifier can help in this sort of case.

     
    Regards, Jon Summers
    LA Solutions

  • FYI and Update:  has filed Defect 1121670 to address this issue in a future release.



Reply Children
No Data