Xforce Keygen 32bits Or 64bits Version HSMWorks 2016
Sibyl Piccuillo
I have a project in Visual C++ (Visual studio 2019) to create standalone exe to manipulate hsmworks. In the project, I have added the reference for the AddinAPI.h and the compiler is now OK with the method names exposed in the hsmworks api.
However, I struggle to link the hsmsw.lib file, also located in the api folder within the hsmworks installation folder. At compile (link) time I get the LNK2019 error (unresolved external symbol) for the HSMWorks_getVersion. The setup looks like following:
I am pretty sure the linking is somehow working, because if I rename the Additional dependencies entry in the linker option I get the "file not found" error, therefore I think that the linker must know about the hsmsw.lib file.
Note 2: If I put the hsmsw.lib file into a specific project directory (I believe into the Debug directory), the HSMWorks_getVersion method works, but while calling any other method I get a null pointer exception.
I would expect that if it can find the .lib then you shouldn't get the linker error. I'm not sure why putting that into the Debug folder would help -- unless that's actually the directory that's specified in your project.
Here are the screenshots that you have asked for. Sorry it is in Czech. Hopefully, they will be delivered to you with their respective numbers. So #1 is the full path to the installation of HSMWorks, against which, as the documentation says, I should be linking. #2 is full path to the Solidworks installation api, from where I include the libraries. #3 is the C++ additional include directories. #4 are additional library directories for the linker. #5 is the input file names for the linker. #6 is the code of the error and its text (unfortunately in czech, but it basically says unresolved external symbol for the HSM_getVersion method). Finally #7 are the include and import directories. You can see pretty much the entire test code in the image number 6, only the getVersion is missing there.
Can you show me what you have defined as preprocessor symbols. It's complaining about the entry point with "__imp__" prefix, which shouldn't be there. Makes me think that HSMWORKS_API is being interpreted as "declspec(dllexport)" instead of dllimport, as it should be.
I have not edited any preprocessor symbols. I am attaching a screenshot of the default preprocessor configuration in the project. Also I have noticed two things. First, there are these lines in the AddinAPI.h of the HSMWorks API:
But I haven't found any definition of the HSMWORKS_EXPORT_API. Also, Visual studio is highlighting it so that the #define HSMWORKS_API __declspec(dllexport) is grayed out, meaning that the code will take the 'else' path (maybe VS is wrong about this?).
Secondly, I am using a 32-bit settings and VS complains that there is a mismatch between this and the 64-bit library. Could this be the issue? But when I switch to using 64-bit I get tons of errors about the SolidWorks types in my main program, even after complete rebuild and I don't know how to resolve that.
I have checked macros in the header file for the HSMWorks API and indeed the HSMWORKS_API macro is being defined as declspec(dllimport), which should be correct, according to what you have said. If I define the HSMWORKS_EXPORT_API macro, then the HSMWORKS_API changes to declspec(dllexport). This is expected and from that I judge that it works correctly.
thank you for your help. I have finally got the project to work, hopefully with correctly linked libraries. There were two issues. First was not running in 64-bit, which was apparently causing the library functions not to be imported correctly, resulting in a build-time error. After changing to 64-bit, I started to get a run-time error of not being able to find hsmsw.dll. The latter was fixed by adding the HSMWorks directory to the system PATH. So now I am linking against the active installation and I didn't have to move any files around.
However, now a different problem occurred. According to the HSMWork docs in the AddinAPI.h, I am supposed to access SolidWorks object to be used in most of the HSMWorks API methods. In the documentation they do it by calling swApp->GetActiveDoc(), but the (current version of) SolidWorks API has no such method as GetActiveDoc. The closest resemblance being get_ActiveDoc(IDispatch** document). Also while programmatically opening the project file of SolidWorks via the OpenDoc6 method, there is a document object being returned as the last parameter (type of that is IModelDoc**).
Whichever way I choose to get the document object from SolidWorks, I always get a null pointer exception when calling any HSMWorks API method that requires the pointer to SolidWorks object (i.e. the swDoc1 and/or swDoc2 variables). I have no idea how to get over this. In the debug info, there is a memory location of the exception, but there is no match between that address and address of any of my variables.
The intention of the program is to have SolidWorks opened manually beforehand (or open it programmatically, but when opening like that, the HSMWorks addin seems not to be loaded correctly). Then programmatically (or manually) open a project file and have the program perform some HSMWorks actions over the opened project (like regenerate all toolpaths - as in the HSMWorks documentation in the AddinAPI.h file).
I'm not 100% sure -- trying to get confirmation -- but it may just not be possible to successfully interact with the HSMWorks API from an out-of-process client. The way it was intended to work is that you have your own separate addin for SWX, running in-process, which can then connect to Solidworks in the same process.
I'm still failing. I will ask: it is possible to provide for download a basic project created in C ++. Just a functional example given in the AddinAPI.h file to regenerate all paths. With instructions on how to implement this API into SolidWorks 19 or 20, or 21
Have you reworked your project to make the connection with the HSMWorks API inside the Solidworks process? If so, what results are you seeing? Are you able to share your project with me so that I can try it here locally?
For one case, I tried to do it on C++ standalone application, which works well.
But in standalone application, it was not possible to feed document variable(SolidWorks) into HSMWorks API, because that variable always considered to be null reference in memory.
For functions, which doesn't require document(for example, bool), it worked well.
" Note: You cannot use a SolidWorks VBA macro since it runs in a separate process so HSMWorks data cannot be accessed. Users must make a normal SolidWorks Add-in (SolidWorks provides sample code). Once users have a working SW add-in, they can then link to the HSMWorks API."
Yes, that's why, I built C++/CLI add-in for SW, which is working properly now.
The problem is, that I am not able to use HSMWorks function with SW document parameter.
For example, SW api function HSMWorks_getVersion is taking int as arguments and this function is returning correct version values of HSMWorks inside SW add-in project.
Thanks to the Autodesk Support a Developers team. Without your active help and modifications in the HSMWorks source code, I could not have created the NejkovAddin extension, which helps me a lot when working in HSMWorks.
I believe that tools will soon be available that will allow me to create a similar application for FUSION360.