Lets Dialog with Qt

[qtoptus]

Hello,

Is there a way that I can create a dialog application without using main() function? I want to call the dialog function from another application function instead that uses a different toolkit/framework. In other words I'm launching the dialog from within the same process of the main program.

Thanks.

[wysota]

Yes. Libraries do not need a main() function. Just export a function that you will call from within the main program. Note however that an instance of QApplication needs to exist to use Qt widgets so either the main application will have to create it or you need to do that yourself in your library function.

[qtoptus]

Great! So this implies a different process will be instantiated for the QApplication.

Thanks.

[qtoptus]

I'm writing a plugin for Lightwave3D which uses Qt for GUI instead of the LW native GUI. However I get this when I start LW:

7853

[wysota]

Most likely you have taken an incorrect version of Qt libraries (the ones for QtCreator instead of those for your apps) when deploying the plugin.

[qtoptus]

I don't use QtCreator. I copied the Qt dlls: QtCore4.dll, QtGui4.dll, and QtOpenGL4.dll from Qt bins to the plugin directory. However when I compile as Debug, and use the debug dll versions I get another error complaining about the MSVCP100d.dll not found...This file does not even look installed in my system.
My platform is Windows 7, VS 2008, and Qt 4.8.1 SDK.

[amleto]

you should take it as a hint that copy/pasting dlls all over the shop isn't the correct thing to do ;)

[qtoptus]

Nothing Qt code related as I'm not using it. just trying to get the plugin loaded properly first. I could upload the project but first I need a confirmation that someone who willing to test it has access to Lightwave 3D 9.6. Otherwise it's useless. The code I have is only LW SDK plugin initialization, nothing more.


you should take it as a hint that copy/pasting dlls all over the shop isn't the correct thing to do

Correct when the DLLs are installed in the proper system directory ;)


Otherwise we are all guessing the problem from a fabrication where relevant details are often missing.

As I mentioned not much details. The problem is very clear, a third party application loading a dll that depends on Qt dlls is failing to load. Clearly something has to do with Qt DLLs. I will try statically link to the Qt libs instead.

[amleto]

That's my sig you are responding to, but thanks for reading :)

[qtoptus]

LoL, sorry! I did not see that.

Anyway I hope it's something I can solve on my end, cause working with LW GUI is a pain... :D

[wysota]

I copied the Qt dlls: QtCore4.dll, QtGui4.dll, and QtOpenGL4.dll from Qt bins to the plugin directory.
What is the exact path to the files you copied?

[qtoptus]

Copied from C:\Qt\4.8.1\bin

[ChrisW67]

I get another error complaining about the MSVCP100d.dll not found...This file does not even look installed in my system.
This is the Microsoft Visual C 10 runtime debug version. It will be installed on any machine that has a recent enough Windows SDK/Visual Studio of some sort installed (I don't know if that is VS 2008 or 2010) as a SxS assembly and also redist file. If you are deploying your release application then you can use the redist package to ensure the release version of the runtime is present. You are not permitted to redistribute the debug library IIRC.

[qtoptus]

I could fix the problem, using a release build only, and a dialog based Qt application rather than a frame window. The plugin loads fine until I create the dialog instance, it crashes. I cannot debug the plugin since I cannot use a Debug version.

[qtoptus]

More details:

extern "C" void plugin_starter(...)
{
//Qt-main-code copied here

// Instantiate dialog class, CRASH!

}

[qtoptus]

Finally this worked! I have the dialog shows within the main program and no problem. After I added a tabbed widget to the dialog, the plugin fails to load again. And I got this message:

7859

I have the correct DLLs QtCore4.dll, QtGui4.dll QtOpenGL4.dll version 4.8.2 and all copied from Qt\4.8.2\bin\

Any idea?

[qtoptus]

Any suggestions?

I'm suspecting it's a problem with Qt build itself since the module is aware of the dependency DLL, QtGui4.dll, but it cannot link to the function, which means a different signature/name mangling...

Should I build Qt from the source?

Can I link to static version of Qt libs?

[amleto]

do you have qt built with the same compiler as your app?

[qtoptus]

I installed the binary version 4.8.2 for the same compiler VS 2008.

[amleto]

how do you build your app, how do you link it with qt?

you will not be able to statically link since you have not built static qt libraries.

and you say you use sdk 4.8.1 earlier in the thread, but now you have installed 4.8.2 binaries? They should be compatible anyway, if built with same compiler.

[qtoptus]

I use VS 2008 and the Qt VS add in latest version. So I create a Qt library, using the Qt Project Wizard, and then add a Dialog box control to the project.

Yeah I decided later to update thinking of this might solve the problem.

[amleto]

'qt libraries' are qtcore4.dll etc. You do not create those from qt project wizard. You either install those, or build them from source.

What you are doing is building qt 'derivative' works/libraries, I believe.

[qtoptus]

I have the Qt SDK installed so I'm using the the Qt dlls from the Qt\4.8.2\bin directory. HOWEVER, now I'm suspicious that the VS Add-in wizard is linking to the wrong version using it's own DLL static link libraries Qt LIBs, while I'm using the installed SDK version.

Another possibility that VS is screwing the hell of the build. I run windows 7 64 bit, the called application (Lightwave 3D) is 32 bit, the VS 2008 is 32 bit, and not sure what bits Qt is built for...

I will try rebuilding from source and using static linking instead, as the entire DLL thingy smells fishy to me...:rolleyes:

[amleto]

I have the Qt SDK installed so I'm using the the Qt dlls from the Qt\4.8.2\bin directory. HOWEVER, now I'm suspicious that the VS Add-in wizard is linking to the wrong version using it's own DLL static link libraries Qt LIBs, while I'm using the installed SDK version.

Another possibility that VS is screwing the hell of the build. I run windows 7 64 bit, the called application (Lightwave 3D) is 32 bit, the VS 2008 is 32 bit, and not sure what bits Qt is built for...

I will try rebuilding from source and using static linking instead, as the entire DLL thingy smells fishy to me...:rolleyes:

You haven't build static libraries so how can the addin link to any static library?
The addin doesn't have its own libraries so how can the addin do that?
What on earth is a 'dll static link libraries Qt LIBS'?

That whole second sentence is gibberish.

the Qt installed libraries and the libraries that are made when compiling from source are 32bit. Even if you build with a 64bit compiler, they are 32bit. There are no 64bit qt libraries afaik.

[qtoptus]

I tried this time linking to Qt static libraries, built from the source. It failed to build. A hell of unresolved external symbols.


What on earth is a 'dll static link libraries Qt LIBS'?

Read, or google.


That whole second sentence is gibberish.

I've no idea what you are talking about.

Anyway it seems that I'm wasting time trying to do something supposed to be trivial but "something" there is broken.

[wysota]

Read, or google.

I also have no idea what this sentence means since DLL resolves to "Dynamic-Link Library" so mixing DLL and "static" in once sentence is a bit like talking about a round square.

If you want to have a static build, then you need:
a) a static version of every library you want to use (including Qt)
b) a static C/C++ runtime (optionally, I think)
c) link your application against a) and b) statically.

If you don't follow this approach then the only thing that is "broken" is your way of trying to solve the problem which is indeed trivial and is well documented both in Qt manual and all over the Internet. Of course you need to be familiar with all the caveats and pitfalls of static and dynamic libraries and mixing them together including the way symbols are getting resolved or not (which probably heavily depends on the compiler you are using). If you do not have such knowledge and are not willing to learn it then the best solution is to rely on the defaults, which in this situation is dynamic linking of everything everywhere and dumping required libraries to a well-known place where the system's dynamic linker can find them when resolving symbols for your shared objects.

[qtoptus]

I also have no idea what this sentence means since DLL resolves to "Dynamic-Link Library" so mixing DLL and "static" in once sentence is a bit like talking about a round square.

My bad I meant to say statically linking to DLLs vs. run-time loading - LoadLibrary(...)

Unfortunately the system is picky about finding the function in the DLLs...something incorrect going on, could be me or something else, and I mean here the LW program not liking the idea of a 3rd party GUI library.

[wysota]

Unfortunately the system is picky about finding the function in the DLLs...
The rules of resolving symbols are identical regardless if the library is loaded upon startup of the application (i.e. library was linked) or runtime (i.e. library was not linked).

[amleto]

I tried this time linking to Qt static libraries, built from the source. It failed to build. A hell of unresolved external symbols.

Read, or google.

I've no idea what you are talking about.

Anyway it seems that I'm wasting time trying to do something supposed to be trivial but "something" there is broken.

1) I still don't believe that you have any static qt libraries to link against.
2) I think you need to learn what some of the phrases you are using actually mean.

For instance - 'statically linking a dll' - that is gibberish. Linking with a dll does not incorporate that dll code into your app/library so it is not statically linked.

[qtoptus]

1) I still don't believe that you have any static qt libraries to link against.

You don't have to. But learn something before you throw some nonsense statements. There's an option that allows you to build Qt as static libraries.


2) I think you need to learn what some of the phrases you are using actually mean.

Don't take it hard on yourself. If you feel you are insulted somehow, then it's because your...complex.


For instance - 'statically linking a dll' - that is gibberish. Linking with a dll does not incorporate that dll code into your app/library so it is not statically linked.

Learn how to talk to people professionally. Your gibberish statements make you look like an idiot.

[wysota]

Could you sum up please what you have done so far step by step? I feel a bit lost here since first you were talking about a plugin with Qt DLLs which apparently worked at some point and then stopped working again after you added something to your program (so I'm assuming you were still using DLLs). Then at some point you started asking about static linking and at this moment I got lost.

[amleto]

You don't have to. But learn something before you throw some nonsense statements. There's an option that allows you to build Qt as static libraries.
I know that, but not once have you mentioned linking with libs, only linking with dlls. Building static Qt libs does not give you dlls... Thanks for teaching me, though ;)



Learn how to talk to people professionally. Your gibberish statements make you look like an idiot.
It's funny how you write that with no sarcasm :)

[d_stranz]

It's funny how you write that with no sarcasm

:D :D :D

Or irony.

I have yet to make sense of what the OP is trying to do, what he has done, or what he thinks he needs to do. If at some point something was working, then he should have stayed on that course instead of trying to "fix" it with all this nonsense about statically linking to DLLs. Sounds to me like there is a compile-time option that is not being correctly specified, with the result that classes and methods are not being exported with the correct mangled names. (The old __declspec(dllimport) / __declspec(dllexport) thing).