As per the title, does anyone know if its possible to prevent reference attachments loading when opening a DGN using OpenDesignFile similar to when the -o switch is used for loading MicroStation from a shortcut?
The reason I ask is I am being plagued by VBA run-time 462 errors with my Excel titleblock editor and one of the tests which has alleviated the error is to detach the reference attachment on the sheet model. Why this would be causing the problem is beyond me and of course detaching the file is not a workable solution hence why I would like to avoid it being loaded instead.
Barry Lothian said:I am being plagued by VBA run-time 462 errors with my Excel titleblock editor
Is your VBA macro loaded from MicroStation or from Excel?
Jon Summers said:Does your VBA TitleBlock Manager use text or tags to display the Excel data?
Barry Lothian said:Tags
Some people have noted that the VBA TagElement.Value property can fail when called from an external app. That property is a VBA Variant: apparently it's implement differently in MicroStation VBA compared to Office VBA. That has never been resolved (or even acknowledge by Bentley Systems).
TagElement.Value
Variant
Regards, Jon Summers LA Solutions
Jon Summers said:Is your VBA macro loaded from MicroStation or from Excel?
Only Excel. Individual files for processing are selected via a file browser and listed in the active spreadsheet. A button then starts causes MicroStation to be opened (but not visible) via OpenDesignFile and the 1st of the listed files is opened, specific tags from a designated tagset are scanned for and if found, their values listed in the appropriate cell and the file is then closed. The instance of MicroStation remains open and the remaining files repeat the same process until complete and the instance of MicroStation closed.
Jon Summers said:Some people have noted that the VBA TagElement.Value property can fail when called from an external app. That property is a VBA Variant: apparently it's implement differently in MicroStation VBA compared to Office VBA. That has never been resolved (or even acknowledge by Bentley Systems).
Indeed I have encountered it (it's been a while so the exact specifics I cannot recall) however that issue does not affect me; the code never fails on the function where TagElement.Value is used.
Though I cannot be sure, I think my issue is some kind of indirect glitch. I typically work with a rigid Drawing/Model file composition and I usually never encounter any issues. Since my last post I have discovered that the issue does not appear to be down to a Model file having more than 1No. model of type Design, instead it appears that it can have multiple however it must be the default model which is attached in the Drawing file's Design model (otherwise the 462 error appears) and that is how I normally work i.e. Model files contain only a single Design model, Drawing files contain a Design model and a Sheet model. I also do not use Drawing Models.
Hi Barry Lothian,
The MicroStation VBA/COM API internally require an underlying owning mdlDescr typically of the calling application (or in this case VBA API), especially when called via COM. For both good software isolation practices and logically debugging and maintenance, does your code succeed when run: a.) within MicroStation and b.) as pure MicroStation VBA code? If the answer (presumably) is yes, the I suggest from your Excel VBA code to reference the (1) correct and running instance (even if you have to start a specific one with a specific workspace/workset required then use GetObject to make a connection) then call the MicroStation VBA macro (passing any required arguments) and MicroStation COM key-ins (load and run vba within MicroStation). This approach helps ensure the code you are attempting to create/run: a.) runs within MicroStation w/o error, b.) direct and easy to debug when there is an error vs. COM errors that don't provide much help to debug, c.) provides improved performance with code running in-process, d.) follows good software isolation and coupling practices.
Can you try to take the above approach in a smaller simplified project to validate if everything works incrementally and let us know if/when something specific stands out as not working to make things easier to confirm and troubleshoot?
Thank you in advance and HTH,Bob