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, ...)
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I'm working on a legacy MFC project. The project includes an SDI application which has a menu-bar.
After launch, the menu-bar for the application is entirely greyed out:
I've read through the following questions, but they don't seem to address my situation:
MFC Menu Item remains grayed
Menu items are being enabled or disabled by default. Why?
Basically, the answers to the above question say that I need an ON_COMMAND handler, which exists for the menu functions I am interested in.
This is a very large proprietary project, so I can't simply post the code, and it could take a while to extract a minimum reproducible example. Is there any function name I can search for which might be disabling the menu-bar?
It looks to me like the entire menu bar is disabled, so I don't think my issue is related to individual ON_COMMAND handlers.
This didn't happen after some change, otherwise I would just roll back the change. I believe the application has been launching with a greyed-out menu bar since I began working on it.
The main application is a CWinApp-derived class, and the class where I added the ON_COMMAND handler is a CFrameWnd-derived class.
I'm developing in VS2019 (v142) using the Windows SDK version 10.0, and testing on Windows 10. I have a feeling (somewhat unsupported) that this particular issue is not closely related to the exact version of the compiler, or even Windows 10; my guess is that I am missing some detail of how MFC enables or disables menu-bars in general.
The "grayed out" means that the widget is disabled.
You'll need to EnableWindow on the widget.
Specifying EnableWindow(FALSE) will disable the widget (window).
The tough part is to find out where or how this function is called.
The state may be specified in a resource file.
It may also be stated in an initialization method, or a constructor.
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.
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 4 years ago.
Improve this question
Recently I made a program by Qt(c++) to get screen resolution and show it by moving mouse. Currently, it works well but just on the MainWindow form;
How can I make it work when I move mouse on desktop also?
I Really appreciate you if you answer.;)
If you want to get mouse input outside of the widget then you have to call QWidget::grabMouse() and later QWidget::releaseMouse() when done. Bear in mind that it may not work on some operating systems or it may stop working when your widget (MainWindow on your case) loses focus. Also it may work worse with next update of operating system. That is because operating system vendors do not like spyware that spies mouse clicks or malware that locks whole desktop.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I've got a slideshow program written in C++ with MFC. It's been working pretty well, with one window showing images on my secondary monitor.
I decided to add an option to display a smaller image (think "thumbnail") on my primary monitor.
When I stop the slideshow, the app makes a call to destroyWindow("Main Screen") which works fine, then the next call is destroywindow("Thumbnail") which hangs up.
While the app is running, I get a crosshair icon over the main screen, and an aero cursor over the thumbnail. If I try to do anything with the thumbnail image - such as click in the image or click resize on the window, it takes a few seconds for the action to take effect.
Any help would be appreciated! Thank you in advance. I'm using openCV2.
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.