 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| 0 user currently in Programming. | 3 guests |
| Acmlm's Board - I2 Archive - Programming - 0 == -1 |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7246/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
I have a program which creates one main window, and then any number of other windows (which are not children of the main window; it\'s just there to catch messages). The main window\'s message handler is ProcMainMessage(), and the others all use ProcMessage() (all are created from the same class). Here is the message loop for both:void ProcessMessages()CurrentWindow is a global variable which the message processing functions use to tell which window a message belongs to. It gets set to -1 for the main window, then incrementing in a loop from 0 to however many other windows have been created for the rest. The problem is when ProcMessage() executes to handle the messages for window #0, CurrentWindow has somehow been set back to -1, as if it wasn\'t initialized to 0 inside the loop, but it has to have been or else it wouldn\'t be processing window 0\'s messages at all (it\'d try to process nonexistant window -1\'s and crash).  I\'m guessing this is a threading issue, since ProcMessage() would be run in a different thread; I tried making CurrentWindow volatile, but it\'s not helping.  (edited by HyperHacker on 09-24-05 01:54 AM) |
|||
Cellar Dweller Flurry !!! Level: 27  Posts: 254/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| Have you created multiple threads? Could another thread be calling ProcessMessages? Why not just have a standard message loop and have windows gain access to their own data by using GetProp? When calling CreateWindow you can use the last parameter to communicate to the message procedure what data it should use, and save data with SetProp while handling WM_CREATE. You can cast a pointer(eg a pointer to the correct WindowInfo entry) or in integer(eg index into WindowInfo) to a HANDLE to store it with SetProp. See the docs for CreateWindow, GetProp, SetProp, RemoveProp, and WM_CREATE for more info about my suggestion. |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7251/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| I only have one thread, but Windows calls the message handlers from a different thread. MSDN seems to be missing their page on SetProp. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 255/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by HyperHacker The only thing that I can think of, assuming that there are no other functions that set the variable, is that ProcessMessages is being reentered before it is finished by being called form within a window procedure. If you have some way to print two different messages, one at the start and one at the end of ProcessMessages, you could check to see if that is the case.(wait, this can\\\'t be because CurrentWindow would equal NumWindows when DispatchMessage returns from a guilty window procedure) Is there is an assignment operator used where an equality operator was intended? SetProp info |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 7261/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| No, I checked that CurrentWindow = 0 before calling TranslateMessage, but it's -1 during ProcMessage. On closer inspection, it actually seems to execute twice, once with -1 and once with 0. The problem is some messages, such as WM_CLOSE (and randomly WM_LBUTTONDOWN, WM_LBUTTONUP, and so on), only get executed with -1, so the window never recieves them. I'm not sure what you meant about using SetProp though. You mean like using that to replace CurrentWindow as a means of checking which window is getting the message? [edit] I tried doing it that way... it almost works, but I get the wrong messages, like WM_NCLBUTTONDOWN instead of WM_LBUTTONDOWN. [edit 10b] Nevermind, I was getting the right messages. Just a stupid mistake on my part. How fast is GetProp though? I ended up using a similar system which goes through each element of WindowInfo and compares the hWnd to the one the message was sent to; I imagine this would be faster, since GetProp is a string-based system, but I don't know for sure. [edit 11b] Don't suppose anyone knows how to get the system's IP address? Or any Winsock tutorials in general, for that matter?  [edit 110b] I can't get borders to work right either. If I create a window without the WS_BORDER style, then later apply that style with SetWindowLong(), the style is applied (window enumeration programs such as Spy++ show that it now has the WS_BORDER style), but no border is displayed. And yet, if I create it with the WS_BORDER style, then remove the style, the border stays! (Again, Spy++ shows that it no longer has the WS_BORDER style, and the window redraws every second.) (edited by HyperHacker on 09-25-05 05:10 AM) |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Programming - 0 == -1 |
| | |
