Hello
I need help with letting the program catch up to the speed of the computer.
I have lines of code that need to audit a file, so that errant blocks that can not be captured by autocad.net can be removed from the file.
However, the audit takes a while, before the audit process itself is over, the code has reached the part where it is checking for the object.
In this case the object is a block.
How can I make the program wait until the audit is done?
If you insert a sleep statement, it delays the audit as well.
Any pointers would be helpful.
Its not clear from your question how you're using your multiple threads, but just in case you hadn't realized (you probably had):
As documented in the ObjectARX helpfiles, the AutoCAD ObjectARX API (including the .NET API) is not multithread safe. What that means in practice is that you should only ever attempt to access the AutoCAD API from your main thread (although it should be fine to process the data you extract from querying the DWG database in another thread).
And just to dot all the 'i's and cross all the 't's for the quoted blog article: The reason we've never exposed a public .NET wrapper for acedCommand is because acedCommand makes heavy use of a technology called Fibers, which the .NET Framework doesn't support - so it is possible that P/Invoking acedCommand from your .NET code could cause AutoCAD or your plug-in to become unstable. In practice, I'm not sure I've ever seen a crash specifically caused by that, but its an area to devote extra special testing to if you do use it.
@StephenPreston wrote:
And just to dot all the 'i's and cross all the 't's for the quoted blog article: The reason we've never exposed a public .NET wrapper for acedCommand is because acedCommand makes heavy use of a technology called Fibers, which the .NET Framework doesn't support - so it is possible that P/Invoking acedCommand from your .NET code could cause AutoCAD or your plug-in to become unstable. In practice, I'm not sure I've ever seen a crash specifically caused by that, but its an area to devote extra special testing to if you do use it.
Well, excuse me, but I'm more than slightly puzzled by the above, and I guess that's because it is simply not true.
The fact is that when they are P/Invoked from managed code, acedCmd() and acedCommand() both behave exactly the same as they do when they are called from native C++. They are both fully-supported APIs in native ObjectARX, and there is absolutely no truth to the rumor you seem to be trying to float here, that P/Invoking either of those APIs 'could cause AutoCAD or your plug-in to become unstable'.