Hi friends :D, i just wanna know why when i make a jump table for my WndProc() with a table length of WM_USER + 1024
the program crashes when i blur the focus from the Main Window... I had to make a CMP wMsg,WM_USER + 1024 and a JBE to make the program not to crash...
I'm using Windows XP Pro without any patches......
the program crashes when i blur the focus from the Main Window... I had to make a CMP wMsg,WM_USER + 1024 and a JBE to make the program not to crash...
I'm using Windows XP Pro without any patches......
Punky,
While most windows messages are well below 1024, in some of the later windows versions, system wide messages are sent at values much higher so using a default over 1024 is the right way to do it.
While most windows messages are well below 1024, in some of the later windows versions, system wide messages are sent at values much higher so using a default over 1024 is the right way to do it.
I'm confused about your answer; as long as i know WM_USER constant's value is 1024 and my table length is (WM_USER + 1024), that's 2048 dwords, the only reason i found is that it uses messages above 2048 and/or maybe a bug in Window XP Pro (Original Release, without any patch or service pack).
Actually Hutch is absolutely correct, many of my applications use WM_APP messages to communicate with each other and those are broadcast to all windows...
As well there are several that are reserved by the system but you are unlike ly to encounter those in a WndProc..
Applications that don't behave and follow the guidelines have a tendancy to crash and burn eventually. you should be calling the DefWindowProc for any messages that you do not process, that includes ones outside of the normal range of messages (0 to WM_USER-1)
Donkey
Message numbers in the fourth range (0xC000 through 0xFFFF) are defined at run time when an application calls the RegisterWindowMessage function to retrieve a message number for a string. All applications that register the same string can use the associated message number for exchanging messages. The actual message number, however, is not a constant and cannot be assumed to be the same between different sessions.
As well there are several that are reserved by the system but you are unlike ly to encounter those in a WndProc..
Message numbers in the fifth range (greater than 0xFFFF) are reserved by the system.
Applications that don't behave and follow the guidelines have a tendancy to crash and burn eventually. you should be calling the DefWindowProc for any messages that you do not process, that includes ones outside of the normal range of messages (0 to WM_USER-1)
Donkey
O.k, i'll try to see what's wrong with the code, maybe i just missed something, and post it here, anyway, thanks Donkey and Hutch.
Punky, if you use a jumptable you really must do bounds-checking on the message rather than blindly jumping. Also, why use a jumptable? It's a waste of space for a WndProc since you're not going to notice any performance difference...
Yes, think you're right, it just wastes space and it's too messy, but i have noticed that using a jmp table for handling WM_COMMAND or WM_PAINT messages it's just fine.
Punky,
If you want to see a jump table dispatcher, have a look at the example code of masm32 "exampl08\dispatch" and you will find 2 forms of the technique, a direct jump table in the WndProc and a message cracker based of the same technique. They are a bit more complicated to set up but they produce a simpler WndProc for bothering and generally smaller code as you don't have the number of CMP/Jxx/LBL code for all of the messages.
It uses 4k of memory but thats no big deal these days.
Regards,
hutch at movsd dot com
If you want to see a jump table dispatcher, have a look at the example code of masm32 "exampl08\dispatch" and you will find 2 forms of the technique, a direct jump table in the WndProc and a message cracker based of the same technique. They are a bit more complicated to set up but they produce a simpler WndProc for bothering and generally smaller code as you don't have the number of CMP/Jxx/LBL code for all of the messages.
It uses 4k of memory but thats no big deal these days.
Regards,
hutch at movsd dot com
Thanks Hutch