 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in Programming. |
| Acmlm's Board - I3 Archive - Programming - DestroyWindow() + Multiple Threads = Bad |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828                    Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6328 days Last view: 6328 days |
| ||
| It seems if I do this:
1) Create a window using CreateDialogParam() in Thread A 2) Create a child of that window, also using CreateDialogParam(), in Thread B 3) Destroy the child window in Thread B 4) Destroy the original window in Thread A The DestroyWindow() call in Thread A pukes and throws an exception. Delaying several seconds to ensure the child window is destroyed doesn't appear to help. Is this a known issue, or did I screw up somewhere? I know you can't create a window in one thread and destroy it in another, but that's not what I'm doing.  The main window's message handler is in Thread A, and the child's is in Thread B; I'm not entirely sure you're supposed to do that, but it seems to be working.
Oddly enough, this doesn't always happen. When a specific button on the main window is clicked it tells Thread B to destroy the child window, waits for it to do so, and then destroys the main window; this is when it crashes. However, another button destroys the child window and leaves the main one alone. If I click that first, then the button that destroys both, it works just fine.  (It doesn't talk to Thread B at all if the child window doesn't exist.) So it seems to work if both windows aren't destroyed in response to the same window message. (It works if they're done in two different MessageProc() calls.) |
|||
|
OmnipotentEntity Newcomer Since: 12-03-05 Last post: 6520 days Last view: 6520 days |
| ||
| http://www.sowbug.org/mt/archives/000046.html
Happy coding. |
|||
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6607 days Last view: 6607 days |
| ||
Originally posted by OmnipotentEntity Erm.... He already said he's not destroying the window in a different thread 
Anyway, HyperMackerel: The message queue system for each window SHOULD be threadsafe (I can't imagine how it wouldn't be -- considering you can send messages to other, independently running programs on the same computer). So rather than destroying child, waiting, destroying parent -- it might be a good idea to have the message queue do the brunt of the work: When the "destroy both" button is pressed: - Parent POSTS (PostMessage.... do not SendMessage!) destroy message to child, then does nothing - Child Destroys itself upon receiving message - Child thread posts (do not send) destroy message to parent - parent destroys itself upon receiving message That'd be how I'd approach it, anyway. Rather than using WM_DESTROY or similar message here, perhaps a custom message might be a good idea. That way it won't get mixed in with any windows-generated messages. Also -- make sure the child window is completely destroyed before posting the message to the parent window. (edited by Disch on 04-12-06 11:12 AM) (edited by Disch on 04-12-06 11:13 AM) (edited by Disch on 04-12-06 11:15 AM) |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6328 days Last view: 6328 days |
| ||
| Well that's a good idea, but the trick is Thread A has no way to actually determine the child window's handle. Thread B is code in a plugin, which could be giving the window any title, class etc or even not creating one, and it can't be relied on that this code will report the correct handle back to Thread A when it's done. | |||
|
Disch Red Cheep-cheep Since: 12-10-05 Last post: 6607 days Last view: 6607 days |
| ||
Originally posted by HyperMackerel Well the main program doesn't have to actually post the message -- it just has to notify the plugin. Have the plugin export a Kill() function or something which the main program can call, and have that function actual post the message to the child window (I'm assuming the plugin has the child window handle). It doesn't matter whether the main program or the plugin is posting the message, just as long as it gets posted. (edited by Disch on 04-12-06 06:03 PM) (edited by Disch on 04-12-06 06:04 PM) |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6328 days Last view: 6328 days |
| ||
Yay, it works! Thanks!  (Sorry for the delay, I had some more important things to do.)
Hm, while I'm here, is there anything I can do about this? ptr1 = (DWORD64)DebugFunctionPtr[j];
This causes "cast from pointer to integer of different size" warnings when I compile. This makes perfect sense, since the elements of DebugFunctionPtr[] are 32 bits and ptr1 is 64. It works fine, though, so is there some way to make it not generate those errors, or a better way to do this? What I need to do is compare the elements of DebugFunctionPtr[] to a 64-bit pointer returned by StackWalk64(). I want to avoid making the array elements 64-bit, since they only need to be 32; that'd be 4 bytes wasted per element (and there's quite a few). |
|||
interdpth Mole MZM rapist Since: 11-18-05 Last post: 6327 days Last view: 6327 days |
| ||
| Tell the compiler to set lower error outputs | |||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6328 days Last view: 6328 days |
| ||
| Hm, not sure how to do that with MinGW. I tried putting -Wx in the call to gcc, but no matter what number I used it generated a huge load of warnings about seemingly trivial things such as comparing signed and unsigned variables.
Also, whenever any control has focus on my dialog and I press Escape, it activates the first button. It doesn't do this if the child window has focus. |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - Programming - DestroyWindow() + Multiple Threads = Bad |
| |
