.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Reply
Message 1 of 7
Bauron
530 Views, 6 Replies

Threads?

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. 

6 REPLIES 6
Message 2 of 7
hgasty1001
in reply to: Bauron

Hi,

 

Did you see this: Synchronously Send (and wait for) commands  ?

 

Gaston Nunez

 

 

Message 3 of 7
StephenPreston
in reply to: Bauron

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.

 

Cheers,

Stephen Preston
Autodesk Developer Network
Message 4 of 7


@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'.  

 

 

Message 5 of 7
Bauron
in reply to: StephenPreston

Stephen

Thanks for your answer - I posted the question and asked for replies to my email that never came.

I am not Multi-threading, and I have seen Gaston's link before. I have sort of abandoned the whole idea of synchronizing with commands in the middle of a routine

Respectfully
Bauron
Message 6 of 7
Bauron
in reply to: DiningPhilosopher

Thank you for chiming in - I will follow that up if possible
Message 7 of 7
Bauron
in reply to: hgasty1001

I have seen the thread - not helping...

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost