3

It's been several days that I'm on this problem without finding a solution...

I developed a macro for SolidWorks in VB.NET. It uses a COM object from a DLL that I developed in C++. The functions of this COM object take a long time to run (sometimes more than 30 seconds), and also make use of parallelized loops using OpenMP.

My problem is that when I run one of these functions, after ~10s, the program stops responding, and it freezes my UI! The DLL function is running and we can not send an update to the UI with a DoEvents()...

I tried to put the function in a background worker but with COM objects it does not work. The other thing I tried is to make a background worker that accesses my process on a regular time interval to see if it responds. But when it stops responding, I can't force it to answer. The only solution that I found is to change the value of the registry key HungAppTimeout, but this applies to everything on my machine whereas I want it applied to just my code.

Would you have a solution to avoid the "no answer"?

Example of code:

Public Sub StartfunctionCOM()

   Dim Myclass as COMClass = new COMClass
   Myclass.functiontakemanytime() 'time >10sec

End Sub
Alex
  • 3,111
  • 6
  • 27
  • 43
nigavevoli
  • 31
  • 5
  • I think you may need an STA thread in order for it to do COM correctly. One way to do this would be to use the task-based parallelism features with a custom tasks scheduler which schedules onto an STA thread. There is a "parallel extensions extras" package out there somewhere which provides an STA task scheduler. You would queue your work using `Task.Factory.StartNew` and then `Await` the task which would keep your UI responsive. If this works for you, I can write it up as an answer. – Craig Oct 18 '19 at 15:42
  • @Craig may be on to something. When you say "putting the function in a background worker does not work" what do you mean? What exception do you get? – Keith Stein Oct 18 '19 at 19:51
  • I didn't try multithreading in macro only in addins. I suppose it is close. Did you try placing your calling code in separate thread? Or you can modify functiontakemanytime() in the way it creates thread and then starts real functiontakemanytime() – Vladyslav Litunovsky Oct 19 '19 at 00:27
  • https://stackoverflow.com/a/21684059/17034 – Hans Passant Oct 21 '19 at 07:43
  • @Keith Stein. "putting the function in a background worker does not work", that mean when i launch this background worker, it happen nothing and it wait the doevent. And when doevent is call, backgroundworker function is execute but on the main thread... – nigavevoli Oct 21 '19 at 09:20

1 Answers1

0

I have found a solution: I call the function DisableProcessWindowsGhosting in my c++ code. It does not prevent the application from "not responding", but it will remove the automatic Windows response (ie the standard "Application does not respond anymore, wait or kill?" message box).

S.Bo
  • 13
  • 3
nigavevoli
  • 31
  • 5