Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Microsoft provides Windows API to draw GUI on windows. Do all gui frameworks like Qt, Tk, wxWidgets, GTK, WTL, AWT, Cocoa and Swing etc. use Windows API to draw GUI on windows? We use gui frameworks methods to create gui and on backend they also uses Windows API to draw GUI on windows?
Ultimately, any UI framework must use the OS's native UI APIs under the hood, and that is the Win32 API and GDI/GDI+ on Windows, yes.
The controls you see as "Win32" are just predefined classes in Windows. For example, a "button" class handles WM_PAINT, WM_ERASEBKGND, WM_LBUTTONDOWN etc to provide the functions you expect (say, the WM_COMMAND when a button is clicked, is posted from the button when it detects a WM_LBUTTONDOWN/UP in it's client area).
For custom controls, not found in plain Win32, QT (and other libraries) provide their own ready-to-use classes with custom messages. Eventually everything reduces to plain WM_PAINT for painting, only that in predefined classes the painting is also predefined.
In theory, a 3rd party library might even write directly to the video card with a driver - in reality however everyone uses the normal drawing API - that is, Direct2D, GDI+ and GDI.
Yes. They all use the Windows API eventually (When run under Windows of course). The Win32 API is the API that can do anything Windows is capable of. The API defines the platform for a developer.
Related
I would like to create a Windows application (for Windows 10) using the C++ and the Windows API. I already have some basic knowledge of using the built-in windows controls to create a basic application, but would now like to expand into custom controls . Since I have no need for my application to be compatible with anything but Windows 10, and would like to use a reliable API which supports transparency and anti-aliasing but is also fast enough to render a GUI, I have chosen to use Direct2D.
The MSDN documentation says:
'Your application should create render targets once'
Bearing this in mind, should each child window use one ID2D1HwndRenderTarget which renders only to the parent window (and doesn't respond to the child windows' WM_PAINT messages), or should there be a single ID2D1DCRenderTarget which would draw to each control using the device context from the WM_PAINT message (using bindDC() - although I would still like to be able to use transparency, and am not interested in GDI interoperability)? Should I even be using Direct2D at all?
I would like to use the Windows API, so a solution involving QT or MFC wouldn't work. I haven't got a specific application in mind, but would eventually like to create a simple library that would enable me to quickly produce GUI applications that have a custom look.
I have spent hours scouring the web for answers, but have found nothing conclusive. MSDN itself seems particularly unhelpful, it just teaches you to draw an ellipse and stops there. Please forgive me if I have accidentally broken the rules of asking questions - as you can probably tell I am new to Stack Overflow - and if any other information is needed, I will of course include it (I am using C++ with Visual Studio Community 2019).
I like C++, and I have used GUI many times in C#, but this time I would like to make a GUI in C++. I already know the basics of the Win32 API, such as creating a window, resource scripts, commands and processing of commands, and the basics of some controls.
But what I would like to know, is how to choose between pure Win32 API or MFC to make applications with sidebars that can be disconnected and connected from the window just by clicking and pulling, as the image below:
And the other type of control I'd like to know, is what kind of list is this in red in the image below? In the bottom circled, I know it's a mix of tree view with that kind of list. I thought it was a table control or similar, but it is not.
Anyway, I must continue studying pure Win32 API, or should I jump directly to MFC? I do not intend to use .NET or C#, only pure C++ with some libs.
You can also take a look at more modern C++ gui frameworks, like Qt.
If you want to learn more about Windows, you can use either Winapi or MFC. //MFC is just a pretty thin (and oop) layer over Winapi.
QBittorrent is using Qt framework, so those are most likely a QListWidget/QListView and QTreeWidget/QTreeView.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Context: a native C++ desktop application that runs on Windows. The GUI uses plain old GDI and standard controls. The application itself is not GUI-rich but all the standard controls I use (static, button, edit and list as a base) are either owner-drawn, custom-drawn, or a mix of both.
My question is about some parts of the GUI I draw directly onto the dialog/window. Each one of these parts is clearly delimited by a rectangle, which is kept as a property for fast access, and these parts get painted only when their respective rectangle overlaps the one that comes from the WM_PAINT and similar messages. Mostly to draw text and icons (transparent background). These parts don't require any end-user interaction but they display valuable information (think status bar or any other GUI element that reacts to a state change).
The result is smooth and flicker-free thanks to the use of some tricks gathered here and there.
Q: Still, out of curiosity, I wonder in such a case (i.e.: non rich application) what would be the benefits of creating a child window for each one of these "parts" instead of just sticking to the current all-in-one drawing technique? Is there any reason why I would have to think about creating children windows?
From where I stand, I see only cons of creating children windows since it would mean more resources (children windows plus their context), plus having to deal with their procedure, which means more code to write-then-maintain.
Answering my own question a few month later...
The way the described application works is just fine as long as the amount of code to deal with those fake control rectangles (content and drawing) does not bloat parent window's code. Also, this technique spares the application from the creation of any resource associated to additional (child) windows, which cannot be a bad thing.
That being said, in the case of a layered parent window that is updated only with UpdateLayeredWindow, it can be preferable (more speed-optimized) to create child controls, especially if we need to update their content quite often.
The benefit of using child windows is simplification and code reuse. Microsoft has implemented many standard controls, and others are available from different sources, all of which are implemented as independent windows. A window will get messages directed at it so that the parent does not have to include logic to determine which function needs to respond to a particular message.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am writing a program that firstly shows Java GUI using JNI and then calls Windows simple GUI.
IF I call Windows simple GUI without calling Java GUI, it shows on the top of other windows so I can see it directly right after it starts.
the problem is, if I call Windows simple GUI after calling JAVA GUI, it shows its windows simple GUI at bottom of other windows: other Windows just hide it.
Here is a picture, you cam see my simple Windows GUI has been hide by visual studio when it starts.
I am not sure I understood the question but I am going to try to answer anyway. What I understand is that you are launching 2 programs and you want to bring one of them to the front of the desktop.
I suppose that you are using CreateProcess to start the programs. There are flags that you can set in the STARTUPINFO structure (wShowWindow), so see if you can use that.
Otherwise you can try calling ShowWindow after launching both programs (and possibly waiting for the Java program to start). You will need to pass the window handle to this function.
You can obtain the window handle by calling EnumWindows, checking the executable file name for each window using GetWindowModuleFileName.
Pseudo code:
foreach window in EnumWindows()
if GetWindowModuleFileName(window) == "program.exe"
ShowWindow(window, ...)
I am writing a C++ application and I have a Login Box that's shown in a regular Dialog Box Frame. I see that some people can SKIN the entire dialog box and makes it look really nice. I was wondering if anyone can give me some pointers as to how to do that.
I'd need more details to give you a good answer.
The answer very much depends on which OS you're using and how you're programming your GUI (for example on Windows - plain Win32, MFC, ATL, Qt, Windows Forms, WPF etc etc).
If you're just using the Windows API here's a link to get you started.
http://www.codeproject.com/KB/dialog/skinstyle.aspx
Beware: custom skinning dialog boxes can be a very large task if you want to customise the look of every control as you end up writing very complicated custom controls.
Alternatively do you just want to make sure that your dialogs appear with Windows XP visual style rather than pre-XP style? This will require changes to your application to use the new common controls and visual style. Note that this changes the behaviour of some Windows APIs and can potentially have side effects (see ISOLATION_AWARE_ENABLED).