Just write the addin.
Then anything else can communicate with that add-in using
So dim myaddin as addintype = swappable.GetAddinObject(Guid of your addin)
Now you have the live instance of your addin inside of solidworks.
Anything made public is accessible. Basically you can do whatever you want it to do.
No need to run solidworks in a separate .exe.
Since the solidworks objects are thread safe as i understand (because they are com objects ), you shouldn't have any issues with that.
Are you sure that no ADDIN2 is needed in order to access ADDIN1 API? The exe runs in different process that ADDIN1 ..
I have addins talking to addins.
I have externals talking to addins that launch externals.
I can assure you you can do it without launching it in a .exe.
What is the purpose. Is it to do a client server application?
Addin1 is com visible. Kind of means it can be accessed by anything.
Unless of course you have the code locked or something weird like that
My intention is to lunch SolidWorks from an console application (.exe file) in the background and to access the API functions of a particular add-in. I'm not sure but you can consider it similar with a client server application because the computer with SolidWorks is like a server. Ideally I like to have the exe runs on o different computer in the network using the SolidWorks from the "server"
In this moment I need to test the communication@ mechanism only on the computer with SolidWorks .
I will test your idea it sounds too simple!
To do this you will need to basically call the server with the code requests.
The server side will need to have basically every method that your add-in contains so it can basically act as a marshaller.
What i did to accomplish this was create a single exe. That exe had the capability to be local or talk to a remote system if local it executes against it's self. However if it is remote it calls to the server which is through interop also. Basically this exe needs to have the methods exposed that your add-in has. Then it wraps those methods to execute either remote or local.
The remote side is the exact same .exe as the local.
One install, one set of code to maintain.
Dim serverside as swclientserver
Sub new(byval executeremotely as boolean)
Function getface as face2
If islocal then
After spending hours I can get the IDispatch pointer to ADDIN1 (the third party add-in which includes the API I try to access).
Unfortunately I'm blocked in the early binding access from pDisp to AddinObject.
int _tmain(int argc, _TCHAR* argv)
int status = 0;
pDisp=pSwApp->GetAddInObject(_T("ADDIN1.ADDIN1")); // OK!!
// CComPtr<IADDIN1interface> AddinObject; // no type library (ADDIN1.tbl) file access for ADDIN1
// AddinObject->ADDIN1_API_Function1(); // the final stage..
pSwApp = NULL;
Any idea is welcome!
I don't know c++ at all but i can read what you are doing.
Does addin1 not implement idispatch?
If not i read possibly use memberinfo.invoke?
These are shots in the dark here. If you wrote this in .net it would more than likely work.
After look in the registry and searching all interfaces available on my computer for ADDIN1 I do not found any interfaces that I can access. The API functions of ADDIN1 are available for accessing only through LoadLibrary(.dll) and functions import at runtime using GetProcAddress() so I try to figure out how to create the second add-in ADDIN2 and link those 2 by some inter-processing mechanism, I do not know...
Anyway, thank you very much for your suggestions, I learn from it!