Multithreading and SolidWorks

Hi,

I am developing an application that works with SolidWorks, and I want
to make this app multithreaded. Is this safe? Does SW distinguish
between threads that do work on parts, components etc.? The app is
programmed in VB.Net.

Best regards
Pål Eilertsen

 

Probably not.

Does VB.NET *have* threads? I know that VB kinda sorta has
multithreaded capability via DoEvents, but I don't know much about
VB.NET having more/less/same functionality.

In any event, the SW API doesn't deal with threading much at all. The
rules that apply are the same rules that apply to COM. The bottom line
is that if you want to access the API from multiple threads, you have to
be careful about marshalling interface pointers when necessary. In my
Java API, the only place I really had to marshall so far is when passing
around the ISldworks interface pointer between threads, such as when
starting a new Java addin on a new Thread. Since all subsequent API
calls by the addin are rooted in this pointer, marshalling it and
allowing the addin to unmarshall it from its thread does the trick.

I've done simple tests with two separate addins starting up on separate
threads and the marshalled pointers seem to work.


Jim S.

 

Jupp. VB.Net is a big upgrade from VB 6 and has all the functionality
that the .Net framework offers.

What I'm doing is to have a thread start an automated process that
creates splines round certain objects. In using another thread to do
this it frees up the UI to let the user continue working. And as long
as the second thread is running everything works fine. When the
automated process finishes (and the second thread dies) _almost_
everything works fine. The error I get is that an object is not set
when I try to change a component2's visibility state. Can it be that
the list of pointers to these components are no longer available for
the main thread?

Best regards
Pål Eilertsen