We've just recently switched our C++ MFC Application from VS2005 to VS2008. Unfortunately in doing so our UI has appearance problems, with things like group boxes appearing blue rather than black, properties dialogs having a white background etc. I presume that in VS2008, MFC has been changed to respect the OS theme (in my case XP default theme). Unfortunately, changing all our controls and our custom toolbars to make the app look decent again is going to require a lot of work.
So, does anyone know if there is a way in code to put the app back in VS2005 mode? I found the following code
typedef void (WINAPI *tSetThemeAppProperties)( DWORD );
tSetThemeAppProperties pSetThemeAppProperties=0;
HINSTANCE handle = ::LoadLibrary("UxTheme.dll");
if (handle)
pSetThemeAppProperties = (tSetThemeAppProperties) ::GetProcAddress(handle,"SetThemeAppProperties");
if ( pSetThemeAppProperties)
{
// call function
pSetThemeAppProperties(0/*dwFlags*/);
}
::FreeLibrary(handle);
Which does stop the XP theme being picked up, but turns off ALL themes and leaves the application looking more dated than it did in VS2005.
thanks
It may be that VS2008 is including a Manifest file in the project that loads the version 6.0 comctl32.dll rather than the 5.82 comctl32.dll... both ship with Windows XP and newer.
Under "Properties->Configuration Properties->Linker->Manifest File", set the "Generate Manifest" option to "No".
Then add your own manifest file if you like, and set it under "Properties->Configuration Properties->Manifest Tool->Input and Output", "Input Resource Manifest".
Just make sure that if you add your own manifest file that it doesn't contain the reference to commctl32 v6.
Related
I created a tableview with model, but the font is not the native system font. It currently looks like this (a combobox inside the tableview):
But in another textinput in the same application it looks correctly like this:
I use no custom fonts and have not overridden the Qt::FontRole (return invalid QVariant()). Why doesn't it use the system font? This is on Windows 10.
EDIT:
There doesn't seem to be any issue when running the executable on my laptop. I'm suspecting a mismatch in .dll files. It should be using the exact same ones but perhaps its using .dll files it finds on my system PATH.
EDIT:
After checking with ProcessExplorer it seems that it loads the correct dlls which are exactly the same my other system loads. The Visual C++ Redistributables versions are also exactly the same.
EDIT
Tried with Visual Studio 2017 (from 2015) with fresh Qt installation, but that doesn't solve the problem either.
Is there a cross-platform way to set the application icon with CMake? I am using Cmake 3.0.2 with Qt 5.4.
In the Qt documentation a method is shown but it is not cross-platform.
CMake doesn't handle this for you.
On some platforms are are several "application icons". For example, on a UNIX-like system which follows the FreeDesktop.org standards (essentially anything you can see today on Linux, no matter if it's KDE, Gnome, Unity, XFCE or some other DE-du-jour), this is done by setting an appropriate Icon entry in the application's .desktop file. See the .desktop spec for details. This is what gets shown as a launcher's icon, and some DEs such as the recent Plasma will use this for a window icon in the taskbar, with appropriate theme overrides.
Maybe you are shipping a Windows installer, too, perhaps based on the NSIS. Then you should probably specify this in your .nsi as well.
Actual window icons are something which should be set up by the programmer, too. As you can see, there's plenty of places where an "application icon" might be set. If you're looking for a real-world example, check out Trojitá's source code. Look for actual icon file installation through CMake, for the NSIS code, for creating a Windows RC file, and finally for setting the application icon from the C++ code.
I have a QtWebKit application and I want to avoid DPI awareness. I tried adding a manifest as documented in MSDN but it only worked in Windows 8.1 (not in Windows 8 and lower versions.)
Inspecting the Qt source code (4.7) I found inside the file qapplication_win.cpp the following snippet:
// Notify Vista and Windows 7 that we support highter DPI settings
ptrSetProcessDPIAware = (PtrSetProcessDPIAware)
QLibrary::resolve(QLatin1String("user32"), "SetProcessDPIAware");
if (ptrSetProcessDPIAware)
ptrSetProcessDPIAware();
For more information take a look at the Commit
That said, I don't really know why it's working in Windows 8.1 and more importantly how can I disable this Qt feature... any Macro/Qt API I should use?
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.
Guys that is code copied from a book (Programming Windows 5th edition):
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0) ;
return 0 ;
}
Link to the topic in which this book is recommended.
Can't compile it with VS2010. What am I doing wrong?
Error 1 error LNK2001: unresolved external symbol _WinMainCRTStartup
Thanks.
It will depend on how you set up the project. In VS2010, if I create a new project via File->New->Project, Visual C++, Empty Project, then add a new C++ file, and copy your code in, it compiles and runs just fine.
If you've created a different type of project, it may be using different link libraries. Try right-clicking on your project in Solution Explorer, going to Properties->Linker->System, and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)
The Win32 APIs are old, but for the most part are perfectly usable if you want to do native Windows programming. Windows has done a great deal of work to ensure that as long as you've followed the documentation, old APIs will not change. You can still compile 16-bit Windows 3.1 code from 1992 and run it on 32-bit Windows 7.
Edit:
It could also be that in Properties->C/C++->Advanced, you have Omit Default Library Name set to "Yes", you probably want it set to "No"
Or also Properties->Linker->Input->Ignore Default Libs should be set to No.
You need to set the project's linker settings to create a Windows GUI program rather than a console program:
"Linker/System/SubSystem" should be set to "Windows (/SUBSYSTEM:WINDOWS)"
Usually this setting gets set properly when you create the project and choose a Windows GUI Application template. Unfortunately, if the project is set to the incorrect application type, the setting is a bit buried (it took me bit of digging to find it).
Make sure you have actually added the source file to the project. This worked for me.