Solved changed compile methods and now external dll cant be instantiated
-
but again i just find it strange because the dll is compiled in visual basic and it separate from the program . I dont get how QAxObject would have trouble init the dll with a autotools exe. the program is not dependent on having it but its a features part that need it if they are to be used. the code there has not been changed and unfortunately the error messages about not init is not giving any details as to why. with no code changes just compile method changes this shouldnt be an issue. the dll is called BoincStake.dll and anyway heres the section of code that makes it work for the old method but not new.
printf("Instantiating globalcom for Windows %f",(double)0); try { globalcom = new QAxObject("BoincStake.Utilization"); printf("Instantiated globalcom for Windows"); } catch(...) { printf("Failed to instantiate globalcom."); } bGlobalcomInitialized = true;
globalcom is static QAxObject *globalcom;
-
forgot one more thing. the autotools was done also to include all the qt static libraries in the exe to reduce the amount of files being installed for the application. basically all we got to install is the exe and the vb dll and itss dependencies.
-
@iFoggz Normally I would say this is because you mixed compilers but since it's a COM component it shouldn't matter.
My recommendation here is to use procmon to see what is happening when it tries to open the com object. You can get procmon from microsoft's website now-a-days.
Also, is there any qDebug output on the console at all? A lot of times when there are issues with something like that Qt will print debug messages on the console in a debug build.
-
thx for the reply and yes i agree. i'll see if itll squeeze anymore information out of it besides the original message error from above
-
Since you mention that you are using a static build of Qt. Did you also use the qmake from that static Qt to build your project ?
By the way, beware of the licensing constraints that comes with the use of a static Qt.
-
defiantly found something interesting with process monitor.
It pulls the CLASS ID from the registry and when i look in the registry at that location it is reading a completely different result then in that specific key then it tries to open Program Files\our app folder\that class id instead of the DLL strange behavior for that exe. never seen it pull incorrect data from registry that is not even in the registry as that. and that CLSID does exist thou elsewhere in registry for the dll which is weird. i think i'ma try to see if i can use CLSID instead and hopefully it points to the dll thou in a perfect would I would be able to QAxObject("c:\programfiles\appfolder\BoincStake.dll") and it'll enter at the Utilization point
-
@iFoggz COM is awful.. Gotta be one of the worst things Microsoft ever created. It doesn't surprise me that is happening at all.
You can try registering your component (in your directory) with regsrv32 as well.
But at least you know your problem now. It should be fairly easy to solve.
Do keep in mind the license issues @SGaist mentioned. If you aren't using commercial licenses for all your developers you can't use the static linkage.
-
thx and yes i'll mention to the developers. our project is open-sourced. we just chose to move to compile the windows exe with auto tools with qt librarys static in it
-
and i should mention the dll does not contain any qt related items and its open-sourced
-
anyway thanks for the help i made an msi installer with the dll and msi regsiters it and the value changed but still using the wrong information so im gonna have to spedn time figuring this out