I'm using asserts in my C++ code. As you all know, when the assert condition is false, it pops up a window about the error with three buttons: abort, retry and ignore. I would like to have a solution of this two possibilities:
- I would like to disable or delete the button "retry" from the windows that pops up
- I would like to define the button abort or the button ignore pressed as default.
Do you have any idea how to do this? It would be great to have a solution to solve that
Thank you very much in advance
Regards
If you need custom functionality then I'd suggest writing your own assertion handler is the easiest and most flexible solution. I don't know why you would want to go to the lengths of disabling the 'Retry' though since that's one of the most useful aspects of an assertion dialog: if the assertion dialog goes off then hitting retry will break into the code at the correct point so you can debug the assertion. Could you explain what you wish to achieve by disabling it?
Related
I have a game app that has the ability to go fullscreen and back to windowed when Alt-Enter is pressed. However, when it goes fullscreen, I get the following warning from DirectX:
DXGI Warning: IDXGISwapChain::Present: Fullscreen presentation inefficiencies incurred due to application not using IDXGISwapChain::ResizeBuffers appropriately, specifying a DXGI_MODE_DESC not available in IDXGIOutput::GetDisplayModeList, or not using DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH.
I've already ruled out the second two possibilities through testing, so I know the only reasons left for the warning to pop up are either IDXGISwapChain::ResizeBuffers isn't being used right, or Windows is just bugged. Since I can't debug the 2nd possibility, I'm sticking with the ResizeBuffers problem. To debug this, I want to look at what happens when Alt-Enter is pressed going from windowed to fullscreen. However, the app does not seem to be calling my ResizeDXGIBuffers method; in fact, it seems that Alt-Enter is embedded into windows or DirectX somewhere, and I don't know how to find the chain of function calls that go off when it is pressed. EDIT: When my method is put in the WM_ACTIVATEAPP handler, it is called, but this is not what i meant. If i take it out of that message handler, the window STILL goes to fullscreen, even though I am not calling any functions to make the window fullscreen myself. So Alt+Enter must be automatically calling some internal function to do this.
So that is my question: Does anyone know what function is called by windows and/or DirectX 11 when Alt-Enter is pressed?
EDIT: As the tags for this question say, I am using DirectX 11 on a Windows machine. Specifically, Windows 7 64-bit.
EDIT 2: I now completely eat the Alt+Enter keystroke and manually store the state of Alt+Enter being pressed so that I know for certain only my code is being called. The warning I spoke of above persists, however. I am following the MSDN best practices as well, so I don't know where to go from here.
Try handling the WM_ACTIVATEAPP message.
I do not know which framework you use to create your windows, so I can't tell how to concretely handle this message.
After looking at the MSDN best practices page and re-working my code to reflect all of the practices described, the warning has disappeared. I hope this helps anyone else that has the same problem.
Also, thanks to Hans Passant for the link. I already fixed it by the time you posted it, but thanks anyways.
I would like to prevent the context menu from being closed in my win32 c++ application. I want to prevent closing the submenu when user clicks on a submenu item. Which message do i have to implement/override?
Haven't done win32 dev in a while, however just random thoughts that come to my mind - maybe will be helpful:
1) maybe you could try to show the context menu again right after the item was clicked
2) or do it the complex way - find, then subclass the context menu window, then intercept WM_CLOSE/WM_DESTROY messages
Overall this seems to be a weird thing to want to implement. Maybe the menu is not the right UI element if you want to keep it on the screen after the selection was made. Maybe you need a modeless dialog instead?
Please see the following article.
Hey guys ... Well I'm experiencing this silly problem that whenever I perform a double click event, two mousePressed events are also triggered, meaning that mousePressed event code is also executed twice for no reason .. How can I configure the event such that first the clicks are checked for doubleClick event, and only if this is NOT true, they move on to mousePressed events .. ? Is this possible ?
Before you spend too much time trying to figure this out, consider what Raymond Chen has said about the "Logical consequences of the way Windows converts single-clicks into double-clicks". The techniques he talks about should be easily adaptable to Qt. But also the UI consequences of the "dubious design of having the double-click action be unrelated to the single-click action" - you may be trying to do something that will be confusing to your users (on the other hand - you might trying to prevent something from confusing your users).
Also, the related article, "Why doesn't double-right-click bring up the Properties dialog?" might be of interest.
I'm going to assume you mean for the same widget. The quick and dirty way would be to move the mouse press code into a private method, have the mouse press event set a timer to go off after the expire timer for a possible double click. In the double click code be sure to turn off the timer if it gets called. This will prevent the mouse press event from running twice. In the timer code, have it call the private method.
How would one prevent the little dotted square that appears on a button when it has the keyboard focus in a dialog. (w/ apologies for the technical jargon). At one point I hacked together a solution by subclassing a button WindowProc and subverting some windows messages, but wanted to know the correct way.
There's actually a problem with another control in the dialog also involving the keyboard. This other control is actually also a button, but being used as a group box or panel, not as a functioning button. But when I hit the tab key in the dialog, this group box "button" comes to the foreground obscuring the static controls on top of it, so I wanted to prevent that.
For both of the above, I tried turning off WS_TABSTOP - didn't help.)
Both of my problems mentioned above were solved by subclassing the WndProcs and returning 0 in response to message 0x128 and discarding it. Even Spy++ could not identify this message 0x128, and I don't have it in any header. But its sent to every control in the dialog the first time tab is hit in the dialog.
(I did try BN_SETFOCUS as described above and also WM_SETFOCUS but it didn't help.)
So if anyone knows where to find what windows message 0x128 is...
The correct way is to write your own button control instead of using the default Windows one.
Alternatively, you can prevent if from ever getting keyboard focus.
I am trying to create a simple dialog in MFC using Visual C++. My problem is that when I get the dialog on the screen and try to type in an Edit Box field, if I type the letter 'a' once, it appears in the edit box as 'aaaaaaaaaaa' (that's 12 a's). Furthermore, if I try to navigate around in the box using the arrow keys, the carat moves 12 characters at a time.
It's not just a display error, as the output from the editbox is still "aaaaaaaaaaaa".
I'd post code, but there's really none to post. I added the edit box using the Toolbox in Visual Studio and assigned a variable to it in my class so this isn't any sort of special edit box.
If anyone has any thoughts as to what might be happening it would be greatly appreciated. Unfortunately, I don't know where to begin.
Thank as always.
To debug this, add PreTranslateMessage function to your dialog, and see exactly how many times the keydown is being processed.
BOOL DialogName::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message==WM_KEYDOWN)
{
// TODO: see what is going on here
return TRUE; //do not dispatch this message, so keydown will have no effect
}
return CDialog::PreTranslateMessage(pMsg);
}
Are you capturing any events such as WM_KEYUP in your PreTranslateMessage() function or anywhere else in your app ?
If you have overridden the default handling for keyboard events, it might cause the symptoms you are seeing.
For some reason this brings back vague memories of early struggles with MFC. Have you looked for mutual recursion at all? I was forever doing something in one bit of the app that sent a message (unbeknown to me) that was picked up by another method that called the first method...
My guess is it's one of those smack the forehead ones; it gives me this nagging sense of deja vu that I can't make concrete.
If it's mutual recursion you should be able to see it in the call stack, if you can find the right place for a break point.
Is this happening for a fresh project, or can you recreate this problem in a fresh project?
It'll help discern whether it's something you've done in your code, or your install.
I installed service pack 2 in my WinXp 64 OS and the problem get solved for me :)