EXE vs Add-In

EXE vs Add-In

Anonymous
Not applicable
419 Views
6 Replies
Message 1 of 7

EXE vs Add-In

Anonymous
Not applicable
Hello,

I am about to develop an application using Visual Studio 2005 which integrates Inventor 2008, MS Project 2007, Excel 2007 and SQL databases containing engineering data. I have successfully developed a prototype which I deployed as an Inventor Add-In (using Inventor 11). Everything worked great but constantly launching Inventor to test the Add-In was painful (particularly when testing functions not requiring Inventor such as database access).

What are the disadvantages of creating an EXE which sits in the middle of all the running applications so far as Inventor is concerned? I could test/debug from within the Visual Studio IDE far easier. Can I still expect the same available functionality (such as moving assemblies around, collision detection, changing colour etc)?

Many thanks.

Chris Molland
0 Likes
420 Views
6 Replies
Replies (6)
Message 2 of 7

Anonymous
Not applicable
There are two issues that I'm aware of that an EXE has that a DLL does not.
First is performance and the second is passing any image data.

I suspect the image passing issue will not be a problem in your case but
where it is a problem is if you need to create a button and supply an icon
image or if you need to extract the thumbnail image from a document. These
are the two most common uses. If you're not doing either of these then this
issue won't affect you.

The issue with performance can be a bigger problem. There are two things
that affect the performance. One is that when two EXE's are communicating
they're doing it across process boundaries, which is slower than within the
same process. There's nothing you can do about this. The second is that
the default behavior of any Windows application is to spend cycles
monitoring the user-interface and intermittently handle out of process API
calls. With Inventor 2008 we discovered a way to work around this issue.
Setting the Application.UserInterfaceManager.UserInteractionDisabled
property to True will stop Inventor from monitoring the user-interface and
significantly increases the spead of how it handles out of process API
calls. You'll want to make sure you set it back to False after you finished
whatever you need to because Inventor won't respond through the
user-interface until you do.

There aren't any other issues that I can think of at the moment.
--
Brian Ekins
Autodesk Inventor API
0 Likes
Message 3 of 7

Anonymous
Not applicable
Thank you for your consice reply Brian.

Beyond the 2 important issues you highlighted is there any limitation on the functionality available to a VB application and is the syntax the same. For example could I reuse any of the code I have developed in my prototype?

Would it be sensible to set the Application.UserInterfaceManager.UserInteractionDisabled
property to True when performing sub-routines which communicate with Inventor and then switching it back to FALSE at the end. For example when instructing Inventor to perform Interference Analysis?

Thank you.
Chris Molland
0 Likes
Message 4 of 7

Anonymous
Not applicable
The syntax is exactly the same. Any differences of syntax will be because
of the programming tool you use. For example VB6 will look slightly
different than VB.Net and again will be different from C#, however the API
capabilities will be the same. From Inventor's point of view there is no
difference and in fact it doesn't know which language is calling it.

Choosing to use the UserInteractionDisabled property can be determined
case-by-case. For example, if you have a function in your application that
makes a few fairly expensive calls to Inventor, most of the processing time
is spent by Inventor calculating whatever results you asked for and not in
the overhead of making the call. There are other cases where you may be
making many calls that are fast for Inventor to return the result so you end
up using up a lot of time in just making the call. For example, most
queries that you would make fall in this category. In the cases where
setting the UserInteractionDisabled property will help you can just do as
you suggested, set it to True at the beginning of the function and False at
the end. You'll want to make sure that you handle any errors and also reset
it to False in those cases.

The best way to determine if it's going to help or not is to just try it and
see if there is a difference for your case.
--
Brian Ekins
Autodesk Inventor API

wrote in message news:5644542@discussion.autodesk.com...
Thank you for your consice reply Brian.

Beyond the 2 important issues you highlighted is there any limitation on the
functionality available to a VB application and is the syntax the same. For
example could I reuse any of the code I have developed in my prototype?

Would it be sensible to set the
Application.UserInterfaceManager.UserInteractionDisabled
property to True when performing sub-routines which communicate with
Inventor and then switching it back to FALSE at the end. For example when
instructing Inventor to perform Interference Analysis?

Thank you.
Chris Molland
0 Likes
Message 5 of 7

Anonymous
Not applicable
Thanks for such an informative answer Brian. I shall do some experiments and try it out.

Regards

Chris
0 Likes
Message 6 of 7

Anonymous
Not applicable
you might also consider how the user is interacting with your custom application. For example, is the user interacting primarily with Inventor and the app is using the other programs to access data? Or would the user be interacting with another program, Excel maybe, and the Inventor files just hold data used by the app? In the first example (user is working with Inventor), I'd develop an Add-in. For the second example, I'd develop an .exe.
0 Likes
Message 7 of 7

Anonymous
Not applicable
An important and valuable point Josh.

In my scenario the program I am developing enables a user to create project planning tasks (MS Project 2007) to which Inventor parts/assemblies are associated. Engineering data is held in SQL tables to provide control over planning task creation preventing impossible situations and providing a lookup for other data. Selecting a task or entering a date allows the 3D scene to be viewed in Inventor as it will be during the planning program. My exe/dll will also run through the planning program performing collision detection for each task.

There are periods of intense communication with Inventor (such as looping through all the tasks, changing the location/appearance of the assemblies and performing collision detection) and then periods where the user is creating tasks and generating reports with little impact on Inventor.

Is it possible to create an .exe and if required re-compile it as a DLL? Having developed a working prototype as an Add-In I am aware that there are some extra code elements required to make the DLL work. However could careful structuring of the .exe code enable a DLL to access the same code as an .exe? Perhaps through shared modules?

Thanks

Chris
0 Likes