I have a question about Qt dll's. We createad a plugin for CS4 and CS5 using Nokia Qt 4.7.1 framework. It works fine, but we have to distibute our plugin with two dll's: QtCore4.dll and QtGui4.dll. We cannot put them next to .prm plugin file, because Premiere Pro will not try to find these dll's there - they should be in the same folder as "Adobe Premiere Pro.exe". With CS4, we didn't have any problems with that, but we are having trouble with CS5. CS5 already has QtCore4.dll and QtGui4.dll, but they are old versions.
Our questions are - why does CS5 use Qt, for what purposes, and is it ok if we overwrite these dll's with new ones? Also, when we update PP CS5, it looks like it overwrites Qt dll's with old versions again. Is there any way to avoid it? Or is there any way to store and load dll's that we need from some other place (without using Qt static compilation, of course) ?
I would recommend that you ship the Qt.dll files with their version on them... eg Qt126.96.36.199.dll and then install them in your distribution.
On Windows the place that is supposed to be is...
C:\Program Files\Common Files\[Company Name]\*.dll
It's then your responsibility during installation of the plugin (eg in InstallShield) to make a system environment variable
eg %COMPANYNAME_BIN%= C:\Program Files\Common Files\[Company Name]\
and append ";%COMPANYNAME_BIN%" to the %PATH% so that the .prm dll can find it during launch.
Then you shouldn't get version clashes any more.
No, because CS5 requires 64 bit compilation for plugins and all the version of Qt 64 binaries that we have is 4.7.1. Even if we recompile Qt to use the same version as in CS 5.0.0, after user updates his Premiere Pro to, let's say, CS 5.0.3, he gets newer versions of Qt that may not work with our plugin (Trolltech promised backwards compatibility for their dlls, but in fact it doesn't really work so well). So.. let me ask the question this way - "How can we isolate third party dll's that our .prm plugin uses from "Abode Premier Pro.exe" (without using run-time dynamic linking) ?".
Well the problem is not in where to put Qt...dll. The problem is in the filenames of the dll's. We cannot just rename them because they are not run-time loding dll's. To make Qt dll's with custom names, we would need to recompile whole Qt framework with special keys and in 64 bit mode - it will cause many other problems.