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.
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
When I resize the window for my C++ application and make circling motions (just drag the top-left corner a bunch), it causes a strange artefact.
When I let go of my mouse:
Essentially what's happening is the application pauses whilst the window is being resized. Is there a way around this?
EDIT: Thanks for closing my question guys...
If anyone miraculously finds this question, I was able to find my own "solution". Do yourself a favour and use freeGLUT rather than SDL2, works like a charm, the set-up is much easier too.
Pretty much all window APIs(Win32, GLFW, etc) have some sort of PollEvents() function that takes all the events out of the event queue and processes them. For Win32, you have a callback function that gets called every event and you process them individually until the queue is empty. For GLFW you poll the events, then you read the state of a certain key from the updated input data (As I understand it). Regardless of the specific implementation for input, most PollEvents() functions become blocking when you either resize or move the window. What that means is that it will be constantly receiving events of type window resize or window move, even if there is no change. This causes the rendering to not update, which causes all sorts of weird stuff. The way around this is to put the PollEvents() function on a different thread than the update loop and call it repeatedly. Depending on what API you're using, there might be restrictions. For example, GLFW's PollEvents() function must be on the main thread, forcing the update loop to be on a separate thread. However, the idea is still the same across window APIs.
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.
I am considering a rewrite of an MFC Dialog application I wrote over a decade ago. I originally chose a Dialog application type because in general the user clicks control inputs and the application provides real-time data from hardware via USB and displays the data in edit boxes. The app also writes information to a file. Since the user never does any file editing I didn't see a need for SDI or MDI application type.
I've now learned that the SDI application type along with CFormView provides some interesting advantages such as scrolling, window resizing:
http://forums.codeguru.com/showthread.php?267664-MFC-Dialog-How-to-enhance-a-dialog-based-application-with-Menu-Toolbar
The reason for my rewrite is that my application is un-maintainable and doesn't scale well. Originally I created a CDialog for each type of "screen" that I show but lots of code is common among the various screens. In fact over time I started reusing CDialog classes and with the use of state variables simply hid, renamed, or repositioned many of the controls to make the screen look appropriate in the context of the application.
I tried deriving the CDialog classes from a common base class but I didn't achieve great code reuse this way. I also found that I had common resources that I was constantly passing around to the various windows which just added unnecessary overhead.
As the application evolved it also became difficult to keep track of the state of the application (for processing USB hardware data input, user input, button enabling etc). Using a hierarchical statechart as the basis for my application might clean this up.
Should I consider putting a superset of ALL the necessary controls on ONE CFormView and simply hiding, renaming, and repositioning controls from the very beginning and using a statechart to manage this?
All the examples I see put the code directly in the input control handlers but maybe I should use the handlers to change state and then let the state machine do the decision-making to reduce this spaghetti code.
So my primary questions are:
1. Would SDI would buy me anything for writing and reading files (such as reporting and logging) if the user does not perform editing?
2. Does CFormView make sense?
3. Does it make sense to put all controls on one CFormView instead of multiple classes and Dialog resources?
4. Have you tried using a state machine in MFC such as Boost Statechart or Miro Samek's Quantum Leaps?
http://www.boost.org/doc/libs/1_58_0/libs/statechart/doc/index.html
http://www.state-machine.com/products/index.html
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 8 years ago.
Improve this question
I had a strange problem in an MFC Application that took a lot of time to solve and was hard to detect for me, It was a stackoverflow on the CWnd::DefWindowProc method it was called recursively that happened just for custom button on a specific dialog, that button worked fine on other dialogs.
Later I discovered the problem, the control was subclassed twice in different controls that was a real bug caused by me.
I'm emulating the way of OWL for creating child controls in the MFC, when a user create an instance of control class in the constructor then there is no need to go to the DoDataExchange to call the DDX_Control that is done in the base dialog it iterates over a list of children to call this for them and after the window had got a handle then we will call it's SetupWindow() method it is like the OnLoad on the .NET C#, also a nice thing is that I check first to see if the parent has an item with that ID using GetDlgItem if there is a control on the dialog with this item then it is a resource control and need DDX_Control else if it wasn't on the dialog then it is a dynamic control and I call CreateWindowEx with it's previously saved attributes in Attr member.
That way missed another check and that what caused the stackoverflow in that dialog the programmer created 2 buttons with the same ID [he was depending on the ID for icon drawing and both was used in same job but for different grid controls on same dialog], the user captured there button click using message map inside the button class and called the appropriate routine for that, ...any way when the first one was about to be created it's id was not on the dialog so it was created dynamically, when the second one with the same id we searched the dialog for that ID and yes it was found so it treated it as a resource control and called DDX_Control then it was subclassed twice by that caused a stackoverflow, to fix that, I stored a pointer to the control as property of the window with a special name and when an id is found on the dialog then get it's HWND if it has that property then it is created previously and I need to create a new dynamic one else then it is not created yet.
what I wanted to say don't use DDX_Control for a previously
subclassed control in MFC.
I hope that this text is readable, I posted this question with the answer to help anyone has this problem to find answer, I suffered a lot from it.
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, ...)