I have created a simple window using the Win32 API with C++. The window shows up fine, however, there is no styling to it and thus all the buttons and such on the window appear in the Windows 95/Me Style as oppose to the modern windows 7 look. So, how can I get this modern look?
I have tried using the xml ways stated in this (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx) microsoft documentation but the program does not compile. I believe this to be because I am using the MinGW compiler as oppose to the VC++ compiler but I could be wrong. In addition, I am now trying the SetWindowTheme function but I am unsure as to how this works and how to include.
Some Notes that may be causing the issue:
I am not using any IDE, Just a MakeFile
I am using the MinGW Compiler
The manifest file must be incorporated as a resource in your executable. That's something VS does almost automatically for you; it is possible to do with MinGW too, it's just a little more convoluted. Take a look at this tutorial, in the section "Enabling Visual Styles".
Although the tutorial shows a winxp look, don't worry; once visual styles are enabled, they'll show up as the native theme of your machine.
Related
Let me preface this by stating I have vision problems so I have to magnify my screen upwards of 400% minimum to read most things including code - even when I am using a dark theme as I do when I code.
QTCreator has an issue where it moves the view on me with most keystrokes & actions - usually to the top left corner by the project file listing. I've posed questions to QT Support and even cloned the source for QT Creator looking to see if I could identify a relatively easy fix - to no avail. So now I'm trying to find a free (as in no financial cost) alternative to QT Creator so I can keep programming using QT Creator in C++.
I've tried Visual Studio Community Edition (2017 and 2019) and had problems getting things to build. It seemed like I had to rebuild the entire framework libraries for MSVC or else it wouldn't work. Additionally it seems it finds compilation errors in even the framework source - which doesn't even look wrong to me or I'd try to repair it.
I tried Eclipse (as I'm a Java engineer for my job so I'm familiar with Eclipse for Java and it does not have the problem that QT Creator has. The QT plugin - when I try to put a simple line of #include - It claims "QApplication" is unresolved. I've looked for this and all the answers say about Project->Properties->Paths and Symbols but as of 2019-12 and 2020-03, there are no options in settings for paths and symbols unfortunately.
A colleague suggested CLion from JetBrains but unfortunately it appears you have to pay for that. I have no intention of paying for a compiler or IDE.
Any thoughts on how I can get around this view changing problem or an alternative to QTCreator that doesn't cost money? If there's a setting in one of the applications I may have missed, suggest it with the version of the appication and I'll look for it and reply if it doesn't exist for whatever reason or accept your answer if it does and fixes the problem.
Thank you!
If you are familiar with Eclipse but have issues with the plugins and you intend using it for C++ I recommend checking out Cevelop (https://www.cevelop.com/) it's basically Eclipse but only for C++ and has some optimizations.
If that doesn't work for you technically you should be able to use any code editor like VSCode or Atom, but I do not know how well that works with the Qt library.
CLion is free for students but I think that doesn't apply for you.
NetBeans (https://netbeans.org/) is also free and cross-platform.
(https://netbeans.org/kb/74/cnd/qt-applications.html)
It should be possible to use Qt within the IDE.
I finally solved this amusing riddle so I'll answer my own question.
It drove me half nuts though, so I guess it might help a few fellow programmers.
Problem definition
What I want to do seems fairly simple: create my own widget and integrate it to my own Qt Creator (the version that runs on my local machine, as shipped with the standard Qt install) so that I can use it freely to design my own interfaces with the ad hoc GUI design tool.
Promoting a generic QWidget works adequately, it's just not very convenient.
I thought seeing the widget in the GUI design tool (instead of an invisible rectangle) and having the possibility to modify specific properties (instead of having to do it programmatically) would be nice.
Unfortunately, this did not go as smoothly as I hoped.
I can’t even be responsible for my own compiler!
Using:
a pristine Win 10 on a freshly reformatted system, with no previous compilers whatsoever installed
the default free version of MSVC 2019 (desktop C++ development pack, toolchain v14.26, compiler v16.4) downloaded by the standard installer
the default current Qt v5.14.0 (MinGW and MSVC2017 targets), downloaded by the standard Qt installer.
I started by naively compiling the example (the clock widget) for x64. Nothing happened. Then x86. Same result or lack thereof.
I actually realized this was conceptually wrong just before trying to compile it for MinGW.
Clearly the produced DLL had to match the native format of the actual Qt Creator, so this idea of the makefile magically adding a plugin to the current Qt Creator binary was all rubbish.
I gave up the wishful thought and set off to put the proper bit of DLL in its proper place by hand.
That's where I went astray for good.
I soon saw that the Qt Creator executable being shipped with Qt 5.14.0 has been compiled with MSVC2017 in win32 mode (that's stated in the "about" window, though no precise version of the compiler and/or toolchain is clearly stated, just this rather unreliable "MSVC2017" which is also used to designate an actual MSVC2019 environment).
The path defined in the example project was leading to some cryptic MSVC2017 subtree where nothing happened at all.
Putting DLLs there had no effect. Deleting the ones that were already present had no effect either.
Clearly my version of Qt Creator never used any of these DLLs. I have no idea what use they are supposed to be and frankly I could not care less. It was just another cold trail that wasted a bit more of my time.
Looking at the "about plugins.." window from Qt Creator, I noticed that all plugins listed there were located in <Qt install root>\Qt\Tools\QtCreator\lib\qtcreator\plugins\ (as stated in the windows that opens when clicking the "details" button).
I wrongly assumed this was were all plugins should go.
However, putting the result of the standard example (the cute little clock widget) into this directory did nothing at all.
I then lost a whole day trying to understand why in the blazes this bloody plugin would not show up.
Since the current MSVC integration is somewhat whacky (Qt still refers to MSVC2017 while using the binary compatible MSVC2019), I set out to try and use the v14.16 Microsoft toolchain (the last using MSVC2017 that can be installed with the Web installer).
I never managed to make this bloody older version of the toolchain work.
Frankly this Qt/VS integration is a quagmire. It boils down to calling this horrendous "vcvarsall.bat" command file that sets up a truckload of cryptic environment variables.
As it happens, vcvarsall.bat requires an extra command line argument (-vcvars_ver=14.16) that Qt is unable to pass (it considers the compiler definition invalid instead... What a rotten luck...).
You can still wrap the call into yet another batch file (#vcvarsall.bat %* -vcvars_ver=14.16) and feed that to the Qt compiler setup.
But even then I never could bring the bloody thing to compile.
I got missing includes and whatnot. Clearly the IDE must make some other assumptions about whatever file locations that make it impossible to work outside the "autodetected"' MSVC versions (namely the MSVC2019 current version in the present state of things).
I was mightily pissed off after all this painful waste of time, so I scoured the Qt forums again and got cluttered by countless (mostly Linux) discussions about paths and compiler options. More time wasted. A lot of time, actually.
In a last desperate attempt I used the nifty process explorer (that's right, spying on all resources opened by an executable) to locate the DLLs used by my running copy of Qt Creator. That is when I finally located the go[beep]mn directory.
From there on everything went quite smoothly indeed. Just compile your little DLL and put it in the right place, and Bob will be your uncle.
A bit of bullshit lore
There are two informations that might lead you to think the designer plugins live either in
Qt\Tools\QtCreator\lib\qtcreator\plugins (the path reported by the "About plugins..." window)
or
Qt/5.14.0/msvc2017/plugins/designer (the cryptic install path used by the example project)
Both are wrong and misleading.
Another bit of lore pretends the Qt Creator executable requires the exact same version of the compiler to produce compatible plugins.
This is another piece of bullshit. You can very well compile with MSVC2019 for the current version of the tool, that has apparently been compiled with MSVC2017 (though the about window does not say with which exact version of the toolchain or compiler, alas).
All you need is a binary compatible DLL (obviously), that means a Win32 compilation from a binary compatible Microsoft compiler (which could theoretically be as old as MSVC2015, as far as binary compatibility is concerned, but since apparently nothing but the latest version of the toolchain is likely to ever work, this is of purely academic interest).
It is not even necessary to compile in release mode, apparently debug DLLs work just as well.
Trying to make the previous version of MSVC work is not only a nightmare of undocumented and cryptic failures, it is also totally useless.
And the solution is...
Just build the project for MSVC 2019 (what Qt calls MSVC2017 for some reason) in WIn32/release mode and put the go[beep]mn resulting DLL into this directory:
<Qt install root>\Qt\Tools\QtCreator\bin\plugins\designer
Yup, that's right. You get a Qt\Tools\QtCreator\lib\qtcreator\plugins where strange things seem to happen but no "widget plugin" will ever be loaded, and another Qt\Tools\QtCreator\bin\plugins with a bunch of subdirectories, including the "designer" folder where your little "widget plugin" will finally come alive.
You get also a lot of bullshit and/or outdated tips from various Qt forum threads. Apparently Qt is crawling with a truckload of different "plugins" that don't all live in the same hovel and love to migrate with each new minor version...
I could find no hints or lists of useful directories in the Qt documentation either. And believe me, I did read quite a lot of Qt documentation.
And btw, to make use of your reusable widgets you will still need to provide either their source code or an interface header and some DLL/LIB for linking.
This "plugin" thing is a nice way to integrate your widget to the GUI editor, but it will not install a library containing your widget nor its interface header (that would be a nifty trick indeed :)).
Bloody awful nightmare. But now it's over and playing with my little custom widget cuties is a load of fun. Yay...
I am new (relatively) to C++ and to SO.
Having stretched the creativity of console applications to the limit, my very rabid mind wants to know how to code GUIs now. I did some research, decided to use GTK rather than Qt because of having freedom of choice, there being no strings attached and something about slow internet and having to download some 0.6GB were I to go with Qt.
It has been a brutal 48 hours trying to build 'Hello World' on Gtk. This is me throwing a tantrum. I'm using Visual Studio 2010. Perhaps this is the source of all my woes. It seems Gtk is meant for C and not C++. After solving issues with header files includes and a certain notorious glibconfig.h missing (which I downloaded from the internet only to find, to my horror,that it is supposed to be a generated file), the compiler threw syntax errors,especially in one gatomic.h.
I suspect 10 errors will come up for every one I manage to solve. This is where you come in. Do you use Gtk to develop c++? If not, why so? What would you recommend instead? Do you use Gtk on windows? How is that possible? Please give details.
Is it possible to make cross-platform apps that use C++ code and a Python/VB GUI?
Your answer will be sincerely appreciated.
First off, a general note: Gtk being mainly developed as a toolkit for Gnome, I think it is fair to say that the main focus is high quality on Linux while other platforms are somewhat second-class citizens. This is probably most visible by looking at the integration with the native look and feel of Windows and MacOS. If you are looking for a toolkit which behaves equally well on all major platforms, I'd recommend you reconsidered Qt.
As far as your more specific questions are concerned:
C/C++
Gtk is written in C, and consequently has a C API. If you are looking for a C++ API, look at the Gtkmm bindings. Note that you can also use the C API in a C++ application.
glibconfig.h
I don't know whether you tried compiling Gtk yourself, but the easiest way to get Gtk3 for windows is by downloading the precompiled all-in-one bundle from http://www.gtk.org/download/win32.php (which includes the glibconfig.h you are missing).
When and how to use Gtk and with what language
As pointed out above, the primary users oft Gtk are people who develop applications for the Gnome desktop environment. Most cross-platform applications nowadays however use Qt since the quality on Windows and MacOS is higher compared to Gtk on those platforms.
Concerning what langauge to use, a strength of Gtk is that there exists bindings for many languages (including C++ and Python), so you are certainly not confined to C.
When developing with C++, something that I personally like about Gtkmm is that it uses the standard library, as opposed to Qt which has it's own implementations for data structures etc (the reason being that Qt predates the times when the STL was generally available and usable on all main platforms).
How to use Gtk: contrary to Qt which has the excellent Qt Creator, Gtk is somewhat lacking a specifically designed IDE for easy development. The closes you'll get is using Glade for interface design and a text editor or IDE of your choice for the coding, but that choice will differ depending on the platform you are on. Clearly, as you probably noticed, integrating Gtk into the environment of choice usually requires some work (and also some more technical knowledge). So again, if you are looking for an easy to set-up and use environment for developing GUI applications, I'd just go with Qt and Qt Creator.
Cross-Platform apps
First off, Visual Basic is not cross-platform. But generally speaking, there are plenty of possibilities for doing cross-application development, using various languages.
I've had to get a gtk3 project working on windows a few months ago, when gtk3 just came out for windows. I've had problems compiling it under Visual Studio as well, and posted a question here, specifically this one.
Here's how I got it working on windows:
Download the all-in-one bundle for Windows from gtk.org
Install, etc, set up include/link dirs within the project. (personally, I dumped gtk's folders in the project folder, pointed at "include" as an include dir and "lib" as a link dir, then proceeded to move any files/folders the compiler cannot find around to the root of "include" )
If not set up automatically, add include and link dirs as necessary until the compiler finds all the files.
If using MinGW to compile, it will succeed at that point.
If using Visual Studio, you have to modify gtk headers as described in the gtk mailing list:
In gutils.h lines 82 and 122, and in gstring.h line 129, change
"static inline" to "static __inline".
Blockquote
Note that the modification does not impact MinGW's ability to compile.
I have successfully compiled my gtk3 project on both windows (with either Visual Studio or Code::Blocks) and linux without writing platform-specific code that way. Just don't forget to include the required runtime dlls with the program when you ship it.
this is my first post on this website,
Anyway, I recently started trying to make a win32 app, and its been going well so far. Then I wanted to add aero to my app (as in not just the borders). So I looked it up online and one tutorial said I have to include dwmapi.h. This is in the Windows SDK. I don't know how to add this to Code::Blocks. By the way, I am using MinGW as my compiler. Also I tried using the MSVC 10 (VS2010) compiler in Code::Blocks, but I got a bunch of errors when I tried to use it, relating to the compilers/linkers not being found.
Any help would be great.
Unless you want to do custom drawing of controls and theme interfaces, all you need to do to support the visual themes is to add the appropriate manifest.
If you want to extend Aero Glass into your client area, look at DwmExtendFrameIntoClientArea () and family.
There are various articles and tutorials online about how to use it. I don't know specifics of using it with Code::Blocks though.
Never Mind, I figured it out. I updated to the nightly build of Code::Blocks and it had an easy preset to help me set up the SDK.
Is there anything I should know before converting a large C++ program from VS2005 to VS2008?
I'm working on this very problem right now.
Running WinMerge to see what I've changed...
OK, here is what I had to fix in an huge Win32/MFC client application:
Some MFC functions have become virtual (which were not in the past - CWnd::GetMenu for one, if I recall correctly). Also something related to our legacy mouse wheel support (before Windows had built-in mouse wheel support) somehow broke (I just removed the feature, so I never really figured out why that broke).
Some ATL methods (or method params) have changed to const that were not originally (screwed up my overrides).
The Platform SDK is newer - be careful if you're setting the windows SDK version #defines correctly (we were not in all places - which was dumb). You may now be building with newer versions (Vista/2008) of Win32 structures. This didn't work so great on my XP box.
STDMETHOD now includes __declspec(nothrow) which is 100% right - except this found some problems in our code. Some interface that was written like it would be exposed through COM, but never was, threw exceptions.
The IDE has a bug where disabled breakpoints don't show the hollow circle in the margin if you don't have the break points set to highlight the whole line (which I think is the default for VC++, maybe?).
Most of these issues were due to subtle mistakes in our code or aggressive overloading of MFC/ATL libraries. Since everyone else's code is perfect, you should be fine ;)
At my work we converted a large C++ project from VS2005 to VS2008. There were no issues at all. Needless to say, you should definitely still keep a copy of the old project just in case. :)
Edit: I should have mentioned that the project is meant to be platform-independent, and has no gui components.
If you have to support older platforms, beware: VC2008 is the first version that can't target Win9x or NT4. My company has to stick to VC2005 for that very reason.
If your project is using MFC then you should be aware that it's had a fairly major update in 2008 which could break things. Mostly security and UI updates, so worth doing anyway in my opinion.
See here for more general information on what's changed in VS 2008.
I recently converted a project written using VC++5, which I hadn't touched in 10 years to VS2008. I just loaded the project and let VS2008 convert it. Everything went fine. (project now here: http://www.codeplex.com/Uptime)
In our experience, the projects convert just fine. The only code change we encountered was where _MIN and _MAX were removed - we had to change it to std::min(), etc. Our MFC stuff compiled OK. Our biggest headache was getting VS 2008 versions of third party libraries we bought, and building VS 2008 versions of large open source packages like boost, OpenSceneGraph, and GDAL. Not rocket science - just kind of tedious. I wrote a short synopsis on my blog.
Is there a difference in the syntax that you can't just simply recompile? VS will convert the .sln and vcproj files for you automatically. The rest is just code, and unless you are doing something really strange, it should just recompile as-is.