Some elements in my drawings are reporting "??È" as the ModelName. It looks corrupted, and trying to write that text into a text file will cause an error. Has anyone seen this?
I agree with Volker that without knowing more, it's hard to guess. You do not follow the forum best practices, so it's not clear what product, version, API and language do you use.
In addition to these crucial information, I'd like to ask also about:
Labyrinth Technology | dev.notes() | cad.point
Jan, I may be a chronic "forum best practices" violator.
But in reality, this was meant to be a generic question, to see if anyone has seen this behavior, surely that's a very unique symbol that may rattle some memory. Being general also limits everyone from blaming "connect" or "your drawing is messed up", or "you're not coding right". If it isn't a common issue, then sure I can share details and even provide the file if needed.
Viktor_Kulik said:This is in VBA and the file is opened using OpenDesignFileForProgram
OpenDesignFileForProgram() creates more problems than it solves. DGN elements are stored in a DGN model that is stored in a DGN file. Opening a file is not enough: you must activate or reference a model in order to enumerate its elements.
What happens after you use that method to open a file? As Jan notes, it's hard to provide a diagnosis when the patient is hiding under a table.
Viktor_Kulik said:This error does not show up if I scan the file with OpenDesignFile, but that's way too slow for what I need
Probably because that opens the default model. Why do you think that OpenDesignFileForProgram is faster than OpenDesignFile? What measurements have you made?
If performance is important, then discard VBA and use C++, provided by the MicroStationAPI.
Regards, Jon Summers LA Solutions
Let me climb out from under the table for a min...
I can give you a statistic, when iterating through 100 files looking for various objects the user has requested, I can scan through all 100 in around 2-3 seconds, depending on the objects being retrieved. With OpenDesignFile, I would be able to scan through 2 files in that amount of time (and its the opening/closing of the document that eats 95% of the time). The difference is huge. You're probably thinking if the file is open, then you would be correct, and given the fact that you can't use EnumeratorScanCriteria with program mode, it may even be a bit slower than just running on the ActiveDesignFile.
I understand that there are limitations of opening this way, but for what I am after, this should be doable, and if "it creates more problems than it solves" why is it even available in the API?
Here's the gist of my code:
For Each f In files
Set CurrentCollection = New Collection
Dim dgn As DesignFile
Set dgn = Application.OpenDesignFileForProgram(f, True)
Dim m As ModelReference
For Each m In dgn.Models
CurrentModel = m.Name
The "ScanEnumeratorSlim" method just runs through the enumerator until it finds various objects, if the object can be enumerated (such as cellelement) it submits to it again. The result gets written out into a temp text file where another process parses that data.
Oh, and as far as using c++ for performance, if this was my company, my product, then yea we can talk about that, but since this is something that someone will need to manage after I leave then I have to deal with vba or C# or whatever else that is more likely to be in the skillset of my peers. C++ skill is dead no matter how you slice it, it's not that they don't teach it, and it's not that it's SOOO complicated, it's just that there are much easier alternatives and people gravitate to those, unless their job depends on it. I'm sure you understand what I mean. What is the percentage of c++ content on your site vs VBA or C#?
Viktor_Kulik said:The difference is huge.
Yes, because when a file is opened "normally", all MicroStation "submodules" (RasterManager...) are initialized, styles and other configurations inside the file are evaluated, GUI is refreshed etc. In contrast to it, when the file is opened "for application", the file is just opened and no further action is run. So it's both advantage and disadvantage: It's fast, but available functionality is pretty limited.
But back to original topic: For me, based on the information you shared, it's bug: It worked in V8i but the discussed issue exist in CONNECT Edition. I have not any time to test it, but because it can be checked using VBA code, I hope Artur Goldsweer will be able to help with the issue.
I have tested this issue now with Update 12 and was able to reproduce the problem.The returned string for the name of the model may be correct, empty or strings like "??T". Also the results may vary between different runs.As a workaround the name of the model could be retrieved directly from the model which is iterated.I have filed Defect # 1040373 to address this issue.
Thanks Artur, that is currently the workaround I am using, appreciate you looking into this.