When loading VBA applications in MicroStation/PowerDraft Connect (V10.12.00.40) I get either VBA INTERFACE ERROR: 135 or VBA INTERFACE ERROR: 140. The applications seem to run fine but I would like to get rid of these errors to keep users from thinking there is a problem. I have searched for an explanation of these errors but so far have not had any luck finding anything. Any insight on this would be appreciated.
I am running Windows 7. The errors occur when loading "VBA LOAD app". The MVBA were initially created on V8i. I believe I recreated one MVBA in CE and still got the error but I will need to verify that.
Hi David,
With such low (value) error numbers (taken literally) these both translate to very similar cause/problem:
D:\Data\Dev\bin>net helpmsg 135 An attempt was made to use a JOIN or SUBST command on a drive that has already been substituted. D:\Data\Dev\bin>net helpmsg 140 The system tried to join a drive to a directory on a substituted drive.
Given the above (if true to the problem), where are the VBA file locations (full path and file names) and if over a network drive can you running as current user access these locations through Windows Explorer and validate: a.) the drive letter is correct, b.) the full path and files needed exist, and c.) the running user has permission to list/view and execute?
Lastly if you attempt to load the MVBA files from a local drive (e.g. C: or D:) do they load and properly then?
HTH,Bob
Bob,
The VBA files are located on the C: drive. I took one of my applications and exported all the items. I then create a new VBA and imported all the items. This seems to have cleared the error. I will test a few others and see if this is consistent.
So I tried exporting and reimporting another application. The problem still exists and came back on the first application I tested. Both had error 140.
Full export and import into a new .mvba project is/was a wise choice when migrating code from V8 to CONNECT.
Are you able to test this on a computer running Windows 10 and reproduce the issue?If you only have access to Windows 7 (I don't have available) could you attach/provide one of the VBAs that are failing so we can try to reproduce the issue?
Lastly, if you have some experience or willing to try using Microsoft Process Monitor (procmon.exe) it can often reveal very specific details related to registry, disk, permissions, and even code call stacks (if symbols present) allowing you to diagnose and resolve silent or hard to reproduce issues by recording and it's advanced/helpful filtering.
Robert,
Thanks for you input. I am aware of procmon so I will give that a try. I will try checking on a Win 10 system and look into a few other items.
Same issue on Windows 10. I did not see anything obvious in Process Monitor.
Additional information: If I load the .mvba from the VBA Manager the error does not occur. Only when loading using a key-in or macro and only on the first load. If I unload and reload there is no error on the second load.
Hello all,
we have investigated this issue and found this is a regression from V8i and is reproducible with locked and password protected VBA projects only.Another condition is to use the keyin "vba load" or "macro vba load" to reproduce this issue.This is not reproducible if using "vba run" keyins to load and execute subroutines in a single step.Filed Defect # 1051127 to address this issue.
Best regards,
Artur
I'm having a very similar issue to that above with Connect version 10.13.01.01 that I just upgraded to. I did not notice this when testing in earlier versions. I am also running an old V8i macro that was upgraded to run in Connect. It is also password protected. It appears immediately after executing the macro from a keyin (;vba l gis_tools;vba run loadform).
In addition to Error: 135 I also get a font error stating UM-Menu.dgnlib could not find SHX font PBABOLD. We don't even use any SHX fonts and I have not seen this prior to my upgrade. It only appears when running the Macro.
Mark Itil
University of Michigan
CAD Manager and UofM Site administrator
Mark, I had the same font issue with another font. The solution was to open the dgnlib and use the key-in "DELETE UNUSED FONTS".
Awsome David!! Thank you so much. This solve the Font error I was getting. 2 fonts were removed... I am still getting the Interface error 135 however.... Thanks Again!
Bentley Systems is aware of the VBA Interface errors and will fix in a future release. They don't seem to cause any real issues so for now just ignore them.
Thank you David. Weird I did not see this with our earlier version of Connect (10.12.00.40)