Why execution is faster when mouse moving on screen

[fsanchou]

Hi,

Yes I know the topic can make smile ...

I use Inventor API from external program, application is visible (but sometime I notice this behavior with iLogic).

When I execute a loop in huge collection (on part faces, on part edges, or drawing entities, etc.), I notice program execute faster if I move mouse on Inventor application!

I don’t have specific sample, but would you know why behaviour happens? And how to correct this?

Thanks,

[bradeneuropeArthur]

Maybe it has to do with the screen update of inventor. This is maybe triggered with the mouse move!

[BrianEkins · Accepted solution]

This is a known behavior and is common with among all programs that support a COM API interface.  What's happening is that Inventor has a single main thread that is handling all interaction with Inventor.  This includes using the UI and also external API calls.  Inventor is watching the UI and also watching for API calls to come in from the single thread.  This is one of the biggest reasons that running an out-of-process program is much slower than running in-process.  For some reason moving the mouse causes Inventor to more frequently handle the incoming API calls.

The solution to this is to use the Application.UserInterfaceManager.UserInteractionDisabled property.  This blocks all interaction with the UI and allows Inventor to focus on the incoming API calls.  You'll need to set it to True at the beginning and then back to False at the end so you can interact with Inventor after the program has finished running.

[fsanchou]

Hi @BrianEkins ,

Thank you for that precise answer, it's works properly now.

An initial test take 30s without mouse movement, take 17s when mouse moving and take 16s with UserInteractionDisabled property.

Best regards,

[BenoitLarocque000]

Hi, 

I got the same type of  problem from an iLogic rule that updates drawing view position and scale.

The rule hangs while trying to retrieve a view Width property.

I tried to disable the user interaction without success.

The program can be Locked for 30 or 40 seconds if I dont move the mouse.

the program resume as soon as I move the mouse.

Here is the code that seem to hang. This code is triggered by a trigger parameter and driven by an Inventor Addin.

ThisApplication.StatusBarText = "#2B - ElevationViewName: " + ElevationViewName
	
	Dim CurrentWidth As Double = ActiveSheet.View(ElevationViewName).View.Width 
	Dim CurrentHeight As Double = ActiveSheet.View(ElevationViewName).View.Height
	

Any hint on this problem?

Best regards,

Benoit Larocque

[tolgay.hickiran]

This is absolutely mind-blowing but it works. I don't know what to say really. One of our employees got aware of this situation when he was trying out some sequences of code. This should be put into documentation or something.

[_dscholtes_]

You mean something like this: Improving Your Program’s Performance  (by Brian Ekins, Mod The Machine).

[BenoitLarocque000]

On my side, as a workaround, I found a way to move the cursor from the driving addin and this solved the problem

To be clear, the iLogic code is triggered by an Addin. The addin has a Progress bar dialog box including a cancel button that runs in another thread.

I added a timer on the progress bar dialog that moves the cursor over the drawing area every 20 seconds to  wake up Inventor.    I know that it's really dirty but it solved the problem.

This problem is supposed to be present only when using external executable to drive Inventor. but it is present in iLogic.

If the user runs the iLogic manually and if he doesn't use the mouse, then Inventor "hangs up". And it hangs up always at the same instruction. Then if the user just move the mouse then Inventor wakes up and complete the view update process.    Very funny!!!

Best regards,

Benoit Larocque

[tolgay.hickiran]

No I mean the official help documentation.

[BenoitLarocque]

I didn't find any thing in the official doc about this kind of problem.

Best regards,

[MjDeck]

@BenoitLarocque , please try disabling drawing background updates in your code. If you do that, it should get rid of the need to simulate the mouse move.
This option is "Enable background updates", at the bottom of the Drawing tab on the Tools > Options > Application Options dialog.
To disable it temporarily in code, add these lines before you make any changes that would cause drawing views to recompute:

Dim savedEnableBU = ThisApplication.DrawingOptions.EnableBackgroundUpdates
ThisApplication.DrawingOptions.EnableBackgroundUpdates = False
	
Try

and then after the drawing view update(s):

Finally
  ThisApplication.DrawingOptions.EnableBackgroundUpdates = savedEnableBU
End Try

Try ... Finally will make sure that the existing setting is restored, even if your code had an error.

The view background updates are most useful when you're working interactively. You don't have to wait for views with a lot of geometry to recompute. But they're not so useful in automated procedures, where you might have to read data from a view after it updates.

[BenoitLarocque000]

Thanks MjDeck, I will try this.