This is a part 2 on a question i posted earlier on this forum. The problem:
In a Keydown handler, when a user pressed the VK_MENU key an editbox is created. So far so good. Problem is that the standard behaviour of windows for a KEYUP-message of this key is to open a context menu. I was suggested:
1) to create the editbox in the keyup handler. This is not an option.
2) to swallow the keyup-message. This sounds good.
My question: how to swallow the keyup message? Is it setting up a local message dispatcher that dispatches messages till the keyup event comes in view, and then just trow it away? What happens to the keyboardstate then? I'm using C. A light on the right approach would be welcome...
If you're fixated on WM_KEYDOWN, rather than WM_KEYUP, you have another problem to consider. When someone holds down a key, you get multiple down messages, followed by a single up message.
Are you requiring someone to hold down the menu button? If not, what's wrong with using the UP message? If you are requiring they hold down this button, then a) typing will be hard, and b) you could use the up button to dismiss your edit box.
Answering your question more directly, if you can handle the down message, can't you just handle the up message with 99% identical code:
if (wParam == VK_MENU)
if (wParam == VK_MENU)
You say you're using C, so I assume some win32 code stuff.
Yours trying to help but puzzled why your tying your shoe laces together,
Thank you for your answers, and the time to get the answer. Of course you're right about the button down vs button up. I have to reconcider that. But actually you found out how it really works (WM_CONTEXTMENU). So i'll track that one and throw in the void...
I'm going to implement a hook program to get a snapshot of the dialog when the mouse button is click. But as we know, when the mouse is over a button, such as the "close" button, an effect of glow will be displayed and the snapshot I captured is including this effect. But I'd like to get a snapshot with out the effect of glow or other speciall effect of UI, so is there any idea that I can fix this problem.
I installed VS.2010 yesterday, and to my surprise our project build without any major hiccups!
I do notice now though, that after doing a full/clean compile, if I try to "build" again (which I assume will be an incremental build), it tends to build files that it thinks are stale, but in fact, are not. Nothing has changed to any of the projects.
Anyone seen anything like this?
I've done the usual, check file dates/times vs. system time etc.
I am currently analyzing some nasty application crashes. Fortunately I can already reproduce these crashes within a few minutes and I get a dump that is supposed to be useful (note that it is a crash dump from an optimized release version). Let me outline the code where the application crashes (pseudo code):
int myNumberOfElements = myCalculation();
[...].// some other code, but no assignments or referencing to myNumberif(myNumberOfElements < 1 || myNumberOfElements > 100000)
MyArray* pArray = AllocArray(myNumberOfElements); // dump shows that myNumberOfElements is greater than 10^9
AllocArray unfortunately belongs to a 3rd party library, but it basically calls malloc. It then crashes as it does not check accordingly if malloc succeeded. However, the root cause of this problem seems to be the large number of elements (which is definitely not the result of my calculation). Further there is only one assignment to myNumberOfElements and if used as parameter 'call by value' is used.
What do you guys think, is the dump file corrupt? Is there a way that the stack gets corrupted, causing this problem?
As posted in my other reply I use Visual Studio for analyzing the dumps. I would like to avoid posting a call stack as I think that my superiors would not be very happy finding parts of our code on codeproject (even if they are small and not useful to anyone).