First off, you need to consider the .h file generated by compiling the .ui a file you never modify. Always subclass the form defined in the .h file, then you make changes there. That way you can re-generate the .ui whenever you need to, which CAN be often especially in the early stages of development.
There are plenty of example in the Qt documentation for using the qmake system to generate exes, dlls, etc.How can i get a .exe of the .ui file? i tried to compile the .h file, but it says error and no .exe file is created.
If you intend on using a dll, then you can only make calls into it if you know the function names and signatures. This will usually be defined in the .h file accompanying the dll. If you don't actually have a .h file, then you can make 'extern' statements declaring the signatures in your own code, but you need to know the signatures first.
For linking, at least using Visual Studio's compilers you need a .lib file as well as the dll.
If you're a statically linked file the .lib will contain all the code and be very big. If it's dll, then the .lib will be tiny containing only the locations in the dll of the symbols which have bee "exported". So in you're own project you'd #include the header file for the dll's symbols and link to the small .lib file. At run time, as long as you drop the dll somewhere in the PATH, usually just alongside the exe then it will be called.
I can't remember exactly what happens with GCC / MinGW in terms of if you need a .o file accompanying the dll, but you specify the lib path and target with options -L<path> and -l<libname>
It's not the whole <libname> though, for example if you have libstuff you'd just put -lstuff (Someone correct me please if I'm missing anything here, it's been a while).
Steve York
Bookmarks