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?
Hi Viktor,
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:
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth 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:But in reality, this was meant to be a generic question
In such case, the best practice is to specify explicitely it's generic question :-))))
... but my feeling is that it's not generic question.
Viktor_Kulik said:to see if anyone has seen this behavior, surely that's a very unique symbol that may rattle some memory.
The discussion is a bit pointless, because you have not specified where you encounter the problem. And MicroStation GUI, native code, managed code and VBA are completely different and pretty separated worlds with own set of problems.
Also, you have not shared any code snippet, so how model name was retrieved is not clear.
This is in VBA and the file is opened using OpenDesignFileForProgram, then iterated through elements and ModelName is accessed via:
TextElement.ModelReference.Name
So for example where telem is the text element, I would do something like:
Dim modelname as String
modelname = telem.ModelReference.Name
Its also displayed this way in the Watches inspector.
Ok, now it become clearer.
Two another questions:
Maybe you discovered a bug in VBA implementation, but I am also thinking whether there can be any issue because of OpenDesignFileForProgram (because some limitations exists in this mode).
Regards,
From what I know, the files were created in V8i SS3, and never been in AutoCad. This error does not show up if I scan the file with OpenDesignFile, but that's way too slow for what I need. This was not an issue in SS3, now it shows up on files from various clients.
Viktor_Kulik said:This error does not show up if I scan the file with OpenDesignFile
That's probably crucial information! Regardless of known limitations of "for program" mode, my assumption is that Model names should be always retrieved correctly and when you can confirm it works fine when the same code is used for the design files opened normally, the bug looks quite probably.
Maybe Artur Goldsweer can do some more testing?
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.
OpenDesignFileForProgram()
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?
OpenDesignFileForProgram
OpenDesignFile
If performance is important, then discard VBA and use C++, provided by the MicroStationAPI.
Regards, Jon Summers LA Solutions
Hey Jon,
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 ScanEnumeratorSlim m.Scan Next WriteCollectionToTextFile (f) Next
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.
Hi,
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.
Best regards,Artur
Thanks Artur, that is currently the workaround I am using, appreciate you looking into this.