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.
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
How do I create an SDL2 application, which is event based? (C++)
My current model has an update loop, which just polls input devices, right when I need them, or just leave them alone if the logic does not need it.
However I want to move to an event driven model, however there are a lot of systems which don't update on some event, just update on every tick of the update loop.
How do I deal with these?
Do I add a new thread and interrupt the update loop somehow, when I receive a new event?
There are many ways to implement what you're trying to do, one way I can think of is an events dispatch system. Suppose you have an event manager. Your application can register various handlers for various events with the event manager. Your event manager would listen/poll for events, it then dispatch (call handlers to those that matches the event). Your event manager would have a lookup mapping to keep track of all the handlers to corresponding event type.
To do event-based programming in SDL2, you need to implement part of it yourself. Right now, you probably have a basic outline that looks something like this (+ error handling, etc):
SDL_Init(SDL_INIT_VIDEO);
auto window = SDL_CreateWindow(/*arguments*/);
//create something in the window, possibly in a loop
SDL_DestroyWindow(window);
SDL_Quit();
To do event handling, you need to create a main loop yourself. In this loop, you repetitively ask SDL for the next event, and process that event as soon as it is given to you. You also re-draw the contents of the window in this loop. In game programming (and general UI, to a lesser extent) the standard system is to, over and over, clear an offscreen buffer (an offscreen buffer is just an image that isn't visible to the user), draw to it, and then make that buffer visible (while usually taking the buffer (buffers are just images) that was visible and making that be the offscreen buffer for the next iteration of the loop). The number of times that this loop runs is your FPS value in a video game, and you can measure FPS by counting how many times your loop runs in a second.
bool quit = false;
SDL_Event event;
while(!quit){
while(SDL_PollEvent(&e)){
switch(e.type){
case SDL_QUIT:
quit = true;
break;
//add more event types here as you see fit
}
}
//it is customary to re-draw the window as fast as possible here, to allow for the window contents to change
}
You can optionally write a more complex event handling system to abstract this loop, but a simple loop + switch as shown above is usually sufficient. noobius's answer gives some more detailed pointers on how to make a more complex system if a simple loop+switch is insufficient (Make sure that it actually is! Complexity is the enemy of software development, so simpler is always better all else being equal.)
Reference, to learn more: https://lazyfoo.net/tutorials/SDL/03_event_driven_programming/index.php
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.
(Maybe this is a beginner question for people experienced with Windows message queue handling and dialg boxes. Unfortunately this is not my area of expertise, so please be gracious to me.)
I have a quite simple C++ program in terms of user interface.
It should not be a real console program of several reasons, but it runs unattended.
It is basically a MFC stub without showing a window at all. But sometimes it shows message boxes like :
MessageBox("Question,"XX",MB_YESNO) or so.
The problem is, that, when two questions are posed after each other, sometimes Windows seems to save the mouse click or keyboard click or the user wanted to klick only once, but the hardware send two clicks. So the user has not real possibility to answer the second question, but yes or no is answered from the "ghost" click before.
(There is a word for it, but I don't know it in English. I hope, you got my point though.)
In the command line there is a fflush() for such things. How to handle it here?
I would even use a customized Messagebox, if I find somewhere ready code for it
(and I have not to write it :-)
But I thought, there might be an easy-to-use snippet to delete the message queue of the app before the next messagebox is shown. But all I know about Windows messages is that they exist ;-(
Can anybody help me?
Philm,
Message box is a modal window, hence it has own message loop. When message box is dismissed, its message does not exist, no mouse messages.
Mouse click messages are always posted to a window under the cursor, unless GetCapture is called.
From what you claim, you do not show any window, so no mouse messages posted in the que?
The only way to resolve your problem would be to debug your application or the test project that you write to duplicate this problem. Can you write it and post somewhere for downloading?
The application is of MFC. Sometimes I need to activate the window and display it at the topmost of the screen when it's deactivated, or hidden, or minimized. Here's what I did:
AfxGetMainWnd()->BringWindowToTop();
AfxGetMainWnd()->SetActiveWindow();
AfxGetMainWnd()->SetForegroundWindow();
if(AfxGetMainWnd()->IsIconic())
AfxGetMainWnd()->ShowWindow(SW_SHOWNORMAL);
else
AfxGetMainWnd()->ShowWindow(SW_SHOW);
AfxGetMainWnd()->UpdateWindow();
But I found sometimes the window was not activated and was still convered by window of other appliactions. Is there anything wrong with my approach? How should I fix this?
Thank you very much!
try
SetWindowPos(hwnd,HWND_TOPMOST,0,0,0,0,SWP_SHOWWINDOW);
it should work on all windows, since all windows have the same handle type.
Try also calling SetFocus on the window you want to show.
If that still doesn't work, or doesn't work 100% you could use a hacky workaround whereby you would launch a thread or window timer (timer's easier) which would periodically check to see whether or not the window that you want to be top most does indeed make it to the top of the order. Once this happens, possibly on the first iteration, you kill the thread or timer.
quantity, i see from your profile that you've asked 12 questions and accepted none. i find it hard to believe that none of the answers worked for you. Please consider going through the responses and marking ones that work as answers. 0% acceptance might cause folks to not care to answer your questions soon.
Cheers.