Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Closing a dialogBox in a seperate thread when the program terminates -problems
26 views
Skip to first unread message
R.Wieser
Mar 25, 2013, 5:57:58 PM3/25/13
to
Hello All,
I've got a program with a dialogbox in it, and a thread with another
dialogbox in it.
The thread (and the dialogbox in it) are created before the dialogbox in the
main process.
Both dialogboxes are fully seperate top-level windows (parents for both
defined as Zero), and do not communicate with each other.
My problem is that terminating the process (by closing the messagebox in the
main thread) does not seem to signal the dialogbox in the thread in any way
that its happening. And that creates a problem for me, as I need to do some
"cleaning up" there.
My question: Did I miss something ? A setting ? I thought that a message
was send to all top-level windows before a process terminated ?
Regards,
Rudy Wieser
I've got a program with a dialogbox in it, and a thread with another
dialogbox in it.
The thread (and the dialogbox in it) are created before the dialogbox in the
main process.
Both dialogboxes are fully seperate top-level windows (parents for both
defined as Zero), and do not communicate with each other.
My problem is that terminating the process (by closing the messagebox in the
main thread) does not seem to signal the dialogbox in the thread in any way
that its happening. And that creates a problem for me, as I need to do some
"cleaning up" there.
My question: Did I miss something ? A setting ? I thought that a message
was send to all top-level windows before a process terminated ?
Regards,
Rudy Wieser
JJ
Mar 25, 2013, 11:28:33 PM3/25/13
to
main-thread's dialog is closed?
R.Wieser
Mar 26, 2013, 6:31:39 AM3/26/13
to
Hello JJ,
> Why not post a WM_CLOSE message to the non-main-thread's
> dialog when the main-thread's dialog is closed?
That is what I'm already doing. But I would also like to have the second
threads dialogbox close graciously when the proces gets in any other way
than by terminating the main-threads dialogbox (like error-exits I have no
control over).
Bonkers. After reading my previous post I see that my "(by closing the
messagebox in the main thread)" addition actually muddies the reason for my
question instead of enhanceing it. Sorry.
Regards,
Rudy Wieser
-- Origional message
JJ <jaej...@nah.meh> schreef in berichtnieuws
19b1iobuqqq45.1...@40tude.net...
> Why not post a WM_CLOSE message to the non-main-thread's
> dialog when the main-thread's dialog is closed?
threads dialogbox close graciously when the proces gets in any other way
than by terminating the main-threads dialogbox (like error-exits I have no
control over).
Bonkers. After reading my previous post I see that my "(by closing the
messagebox in the main thread)" addition actually muddies the reason for my
question instead of enhanceing it. Sorry.
Regards,
Rudy Wieser
-- Origional message
JJ <jaej...@nah.meh> schreef in berichtnieuws
19b1iobuqqq45.1...@40tude.net...
Jeroen Mostert
Mar 26, 2013, 7:43:30 PM3/26/13
to
On 2013-03-25 22:57, R.Wieser wrote:
> I've got a program with a dialogbox in it, and a thread with another
> dialogbox in it.
> The thread (and the dialogbox in it) are created before the dialogbox in the
> main process.
>
> Both dialogboxes are fully seperate top-level windows (parents for both
> defined as Zero), and do not communicate with each other.
>
> My problem is that terminating the process (by closing the messagebox in the
> main thread) does not seem to signal the dialogbox in the thread in any way
> that its happening.
No -- why would it? Windows does not consider any thread in the process the
> I've got a program with a dialogbox in it, and a thread with another
> dialogbox in it.
> The thread (and the dialogbox in it) are created before the dialogbox in the
> main process.
>
> Both dialogboxes are fully seperate top-level windows (parents for both
> defined as Zero), and do not communicate with each other.
>
> My problem is that terminating the process (by closing the messagebox in the
> main thread) does not seem to signal the dialogbox in the thread in any way
> that its happening.
"main" thread. There is a thread that happened to be the first one created, but
it isn't accorded any special status by Win32 (some runtimes do have special
logic for the "main" thread).
Closing a window doesn't terminate a process. Exiting a message loop is done by
calling PostQuitMessage(), and even that just posts WM_QUIT for GetMessage() to
terminate on (in the same thread). A Win32 process dies a natural death when the
last thread in it terminates, by virtue of that thread calling ExitProcess() as
part of the outermost frame set up by the kernel.
if you've got completely separate message loops, each of those will need to be
instructed to terminate separately, which means you need to come up with a
mechanism for doing so.
> And that creates a problem for me, as I need to do some "cleaning up" there.
>
> My question: Did I miss something ? A setting ? I thought that a message
> was send to all top-level windows before a process terminated ?
>
sending a message. In fact, TerminateProcess() just instantly kills the process,
do not pass go, do not collect $200. Outside of TerminateProcess(), a process
must decide to end on its own. Every thread must decide to end, and then the
process ends. Normally, a Win32 application would only have a single message
loop so termination is easier (of course actually handling multiple windows
becomes harder -- I consider myself fortunate that I've never had to implement
dialog box message handling in raw Win32).
If you must have multiple threads and multiple message loops, things get
trickier. Posting WM_CLOSE around to all windows is the easiest way of
coordinating termination, provided you know where they are. If not, another
option is to use a global event and have threads use MsgWaitForMultipleObjects()
to take this event into account in addition to the message pump, but it's a
little tricky to use and I'd leave it for the "if you have to" category.
You do not need to worry about unexpected premature endings unless you're
running code that is not under your control which might call ExitProcess(),
which is extremely poor form and should qualify the author of that code for a
beating. Even then there is a way out (DllMain() and DLL_PROCESS_DETACH
notifications) but there is still very little you can safely do in the way of
cleanup except for the bare necessities (flushing open file buffers, that sort
of thing).
--
J.
R.Wieser
Mar 26, 2013, 9:13:41 PM3/26/13
to
Jeroen,
> Windows does not consider any thread in the process the
> "main" thread.
Hmmm ... When I close the process the extra created threads get killed to.
When I terminate an extra created thread the main process/thread just keeps
on going. To me that looks like a special consideration.
> Closing a window doesn't terminate a process.
And I never claimed as much.
> if you've got completely separate message loops, each of those will
> need to be instructed to terminate separately,
And here I never denied that. Worse, I think I even mentioned something
about a some kind of signal send to all top-level windows.
> No, it's the other way around: you end message processing
> (and your process) by sending a message.
The first is incomplete, the second (inside the brackets) is incorrect. It
also has no bearing on a terminating proces as it was written as response
to.
> In fact, TerminateProcess() just instantly kills the process,
Nice that you tell me/us that, but what has it to do with the sitation I
described ?
> Every thread must decide to end, and then the process ends.
Pardon me, but I've observed a different behaviour. The one I described.
The proces gets terminated (either by a call, or by running outof code), and
as a result the created threads get terminated too.
Otherwise I could terminate a process but the windows in the created threads
would happily keep on functioning. As they don't ....
> You do not need to worry about unexpected premature endings
> unless you're running code that is not under your control which
> might call ExitProcess(),
Actually, its the *only* thing I need to worry about. Either hidden
ExitProcess calls, or abrupt terminations caused by illegal memory access
and the like.
For all the other situations there are rather simple solutions. Even if
that means either your Event "trickery" (I think I would opt for a simple
global variable. After all, each process needs to read the handle to that
single Event from somewhere) or to iterate thru all top-level windows of a
process and send them WM_ messages that way.
Regards,
Rudy Wieser
-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
515232a2$0$6944$e4fe...@news2.news.xs4all.nl...
> Windows does not consider any thread in the process the
> "main" thread.
When I terminate an extra created thread the main process/thread just keeps
on going. To me that looks like a special consideration.
> Closing a window doesn't terminate a process.
> if you've got completely separate message loops, each of those will
> need to be instructed to terminate separately,
about a some kind of signal send to all top-level windows.
> No, it's the other way around: you end message processing
> (and your process) by sending a message.
also has no bearing on a terminating proces as it was written as response
to.
> In fact, TerminateProcess() just instantly kills the process,
described ?
> Every thread must decide to end, and then the process ends.
The proces gets terminated (either by a call, or by running outof code), and
as a result the created threads get terminated too.
Otherwise I could terminate a process but the windows in the created threads
would happily keep on functioning. As they don't ....
> You do not need to worry about unexpected premature endings
> unless you're running code that is not under your control which
> might call ExitProcess(),
ExitProcess calls, or abrupt terminations caused by illegal memory access
and the like.
For all the other situations there are rather simple solutions. Even if
that means either your Event "trickery" (I think I would opt for a simple
global variable. After all, each process needs to read the handle to that
single Event from somewhere) or to iterate thru all top-level windows of a
process and send them WM_ messages that way.
Regards,
Rudy Wieser
-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
515232a2$0$6944$e4fe...@news2.news.xs4all.nl...
Jeroen Mostert
Mar 27, 2013, 4:28:34 PM3/27/13
to
On 2013-03-27 02:13, R.Wieser wrote:
>> Closing a window doesn't terminate a process.
>
> And I never claimed as much.
>
>> if you've got completely separate message loops, each of those will
>> need to be instructed to terminate separately,
>
> And here I never denied that. Worse, I think I even mentioned something
> about a some kind of signal send to all top-level windows.
>
>> No, it's the other way around: you end message processing
>> (and your process) by sending a message.
>
> The first is incomplete, the second (inside the brackets) is incorrect. It
> also has no bearing on a terminating proces as it was written as response
> to.
>
>> In fact, TerminateProcess() just instantly kills the process,
>
> Nice that you tell me/us that, but what has it to do with the sitation I
> described ?
>
You know, I was honestly trying to help, not enter into a battle of wits. I'm
>> Closing a window doesn't terminate a process.
>
> And I never claimed as much.
>
>> if you've got completely separate message loops, each of those will
>> need to be instructed to terminate separately,
>
> And here I never denied that. Worse, I think I even mentioned something
> about a some kind of signal send to all top-level windows.
>
>> No, it's the other way around: you end message processing
>> (and your process) by sending a message.
>
> The first is incomplete, the second (inside the brackets) is incorrect. It
> also has no bearing on a terminating proces as it was written as response
> to.
>
>> In fact, TerminateProcess() just instantly kills the process,
>
> Nice that you tell me/us that, but what has it to do with the sitation I
> described ?
>
sorry I couldn't meet your expectations. Good luck solving your problems.
--
J.
R.Wieser
Mar 27, 2013, 8:48:30 PM3/27/13
to
Jeroen.
> You know, I was honestly trying to help, not enter into a battle of wits.
Hmmm ... I'm sorry that I disagreed with you, I guess I should have taken
your word for the plain truth. Even though it contradicts what I think I
already know.
Nahhh.... Thats not the way it works I'm afraid.
For the "I never claimed" response: I said I closed a window. I also
mentioned it was a DialogBox, which means that it "hangs" in that function
until the dialog is closed. The next command after starting that DialogBox
was a RET, effectivily terminating the process.
Maybe you could put your puzzlement in a bit other form than a "Youre WRONG"
statement. They tell me that the form of a question (" Did you mean to say
...") works quite well. Vinegar and honey and all that.
For the "I never denied" response: I already mentioned that I thought some
termination message was send to the toplevel dialogs, which I thought would
be a good indication that I bloody well knew that such a message is needed
for a clean termination of such dialogs.
Apart from that I also mentioned the need for such a signal (Read the third
paragraph in my first message) as needed for a possibility to quote 'do some
"cleaning up" there'. Another indication that I was well aware of the need
for such a signal.
You jumped to conclusions for the first, and missed all of the above for the
second. In the light of that your "you're wrong" attitude irritates. And
that reaped the results for.
Wanting to help is laudible, but please start with listening. You can't
really help without doing that.
Regards,
Rudy Wieser
-- Origional mesage:
> You know, I was honestly trying to help, not enter into a battle of wits.
your word for the plain truth. Even though it contradicts what I think I
already know.
Nahhh.... Thats not the way it works I'm afraid.
For the "I never claimed" response: I said I closed a window. I also
mentioned it was a DialogBox, which means that it "hangs" in that function
until the dialog is closed. The next command after starting that DialogBox
was a RET, effectivily terminating the process.
Maybe you could put your puzzlement in a bit other form than a "Youre WRONG"
statement. They tell me that the form of a question (" Did you mean to say
...") works quite well. Vinegar and honey and all that.
For the "I never denied" response: I already mentioned that I thought some
termination message was send to the toplevel dialogs, which I thought would
be a good indication that I bloody well knew that such a message is needed
for a clean termination of such dialogs.
Apart from that I also mentioned the need for such a signal (Read the third
paragraph in my first message) as needed for a possibility to quote 'do some
"cleaning up" there'. Another indication that I was well aware of the need
for such a signal.
You jumped to conclusions for the first, and missed all of the above for the
second. In the light of that your "you're wrong" attitude irritates. And
that reaped the results for.
Wanting to help is laudible, but please start with listening. You can't
really help without doing that.
Regards,
Rudy Wieser
-- Origional mesage:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
51535672$0$6842$e4fe...@news2.news.xs4all.nl...
Jeroen Mostert
Mar 28, 2013, 2:29:23 AM3/28/13
to
On 2013-03-28 01:48, R.Wieser wrote:
>> You know, I was honestly trying to help, not enter into a battle of wits.
>
> Hmmm ... I'm sorry that I disagreed with you, I guess I should have taken
> your word for the plain truth. Even though it contradicts what I think I
> already know.
>
> Nahhh.... Thats not the way it works I'm afraid.
>
So your approach to continuing a dialogue where the other side gets irritated at
>> You know, I was honestly trying to help, not enter into a battle of wits.
>
> Hmmm ... I'm sorry that I disagreed with you, I guess I should have taken
> your word for the plain truth. Even though it contradicts what I think I
> already know.
>
> Nahhh.... Thats not the way it works I'm afraid.
>
your snark is to use *even more snark*. I am so tempted to say "that's not how
it works, I'm afraid"... but I won't. :-)
> Maybe you could put your puzzlement in a bit other form than a "Youre WRONG"
> statement.
annoyed. But that wasn't my intent at all. Instead, I said what I thought to be
the truth -- throwing up stuff to hopefully establish the context better. Am I
always right? No. Can you point it out when I'm not? Of course. In fact, this is
where an explicit "you're wrong" statement would be appropriate.
I honestly couldn't tell from your post what, exactly, you were saying was the
case. It's nice that you explain after the fact, but it's all I was after in the
beginning.
I'm thinking this is a simple breakdown in communications where we
misinterpreted each other's tone. You thought you stated your case
unambiguously, while I didn't get it.
> You jumped to conclusions for the first, and missed all of the above for the
> second. In the light of that your "you're wrong" attitude irritates. And
> that reaped the results for.
>
can blame me for being dense and hitting the wrong tone if you want, but not for
the actual attitude.
> Wanting to help is laudible, but please start with listening. You can't
> really help without doing that.
>
longer than you usually would. This seems especially appropriate if the person
trying to help you is getting nothing in return for helping you.
In a face to face conversation, I expect we would have had no problems, because
it's much easier to ask for clarification and clear up misunderstandings there.
Online, some patience has to be accounted for.
--
J.
R.Wieser
Mar 28, 2013, 8:35:54 AM3/28/13
to
Jeroen,
> So your approach to continuing a dialogue where the other side
> gets irritated at your snark is to use *even more snark*.
So you didn't ask yourself why the other party was making his initial snarky
remarks (hint: I got *very* irritated whith your attitude), but just threw
it upon me wanting to have a "battle of wits" ? Really ? No
introspection of any kind ?
> I am so tempted to say "that's not how it works, I'm afraid"... but I
won't. :-)
Its called sarcasm, and it looks it already did work. I think I've got
your full attention now.
> If I had said "you're wrong" when you weren't, I could see why
> you'd get annoyed.
Well, you did. Granted, not with those exact words.
> Instead, I said what I thought to be the truth
I'm almost sure that you did that.
Maybe the problem is that I can't really understand how someone with your
apparent knowledge and experience can simply make a statement like that all
threads are equal, without even considering (the described by me!)
parent-child relationship between two of them.
> Can you point it out when I'm not?
Your whole reply was a big chain of "being wrong". You did it so plentiful
that I was really wondering if you did it on purpose, but simply could not
believe it.
> I honestly couldn't tell from your post what, exactly, you
> were saying was the case.
... but you ignored all that "can't tell" and just proceded to take whatever
you than had as "the truth" and proceeded to tell me what I did/assumed
wrong based on that ? Why ?
> It's nice that you explain after the fact, but it's all I was
> after in the beginning.
Did you ask for any clarification ? At any point ? Why not ? Why did
you just continue talking, even though you had no clue if you understood me
right ?
> I'm thinking this is a simple breakdown in communications ...
True. I tried to convey some information, you couldn't quite tell what it
was. You did not try to rectify that situation, or even show doubts to me
to some of your conclusions. The communication was broken from that point
on.
You mentioned my being snarky in my first reply to you (with not so many
words). Any chance you now see that as a result of, instead of the cause ?
> You can blame me for being dense and hitting the wrong tone
> if you want, but not for the actual attitude.
Hmmm... If you mean by "attitude" if I think you did it on purpose ? No,
I don't think so.
As for the rest ? I don't know you long enough to tell what your
true/long-term attitude is, I have to do with whatever snapshot your replies
bring me.
> If I can offer advice in return: if you want help, please assume
> good faith for longer than you usually would
I do. But I do have my limits.
I would like to end this with the words "lets just forget it happened", but
I really do hope you don't. :-)
Regards,
Rudy Wieser
-- Origional message:
> So your approach to continuing a dialogue where the other side
> gets irritated at your snark is to use *even more snark*.
remarks (hint: I got *very* irritated whith your attitude), but just threw
it upon me wanting to have a "battle of wits" ? Really ? No
introspection of any kind ?
> I am so tempted to say "that's not how it works, I'm afraid"... but I
won't. :-)
your full attention now.
> If I had said "you're wrong" when you weren't, I could see why
> you'd get annoyed.
> Instead, I said what I thought to be the truth
Maybe the problem is that I can't really understand how someone with your
apparent knowledge and experience can simply make a statement like that all
threads are equal, without even considering (the described by me!)
parent-child relationship between two of them.
> Can you point it out when I'm not?
that I was really wondering if you did it on purpose, but simply could not
believe it.
> I honestly couldn't tell from your post what, exactly, you
> were saying was the case.
you than had as "the truth" and proceeded to tell me what I did/assumed
wrong based on that ? Why ?
> It's nice that you explain after the fact, but it's all I was
> after in the beginning.
you just continue talking, even though you had no clue if you understood me
right ?
> I'm thinking this is a simple breakdown in communications ...
True. I tried to convey some information, you couldn't quite tell what it
was. You did not try to rectify that situation, or even show doubts to me
to some of your conclusions. The communication was broken from that point
on.
You mentioned my being snarky in my first reply to you (with not so many
words). Any chance you now see that as a result of, instead of the cause ?
> You can blame me for being dense and hitting the wrong tone
> if you want, but not for the actual attitude.
I don't think so.
As for the rest ? I don't know you long enough to tell what your
true/long-term attitude is, I have to do with whatever snapshot your replies
bring me.
> If I can offer advice in return: if you want help, please assume
> good faith for longer than you usually would
I would like to end this with the words "lets just forget it happened", but
I really do hope you don't. :-)
Regards,
Rudy Wieser
-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
5153e343$0$6864$e4fe...@news2.news.xs4all.nl...
Jeroen Mostert
Mar 28, 2013, 3:49:36 PM3/28/13
to
On 2013-03-28 13:35, R.Wieser wrote:
>> So your approach to continuing a dialogue where the other side
>> gets irritated at your snark is to use *even more snark*.
>
> So you didn't ask yourself why the other party was making his initial snarky
> remarks (hint: I got *very* irritated whith your attitude), but just threw
> it upon me wanting to have a "battle of wits" ? Really ? No
> introspection of any kind ?
>
I've taken a long, hard look deep inside myself, and concluded that this
>> So your approach to continuing a dialogue where the other side
>> gets irritated at your snark is to use *even more snark*.
>
> So you didn't ask yourself why the other party was making his initial snarky
> remarks (hint: I got *very* irritated whith your attitude), but just threw
> it upon me wanting to have a "battle of wits" ? Really ? No
> introspection of any kind ?
>
discussion is definitely not worth my time. Especially since it's obvious it
will never end until one of us gets tired. So I'll stop right there.
You win, have a nice day.
--
J.
Geoff
Mar 29, 2013, 3:10:15 AM3/29/13
to
On Mon, 25 Mar 2013 22:57:58 +0100, "R.Wieser" <add...@not.available>
wrote:
Rudy,
Joe Newcomer's site, http://flounder.com has some excellent tips about
thread messaging and dialog boxes. While mostly MFC-focused, many of
the principles are applicable to the Win32 API, especially about
creating threads suspended and only resuming them from the main thread
once CreateThread has returned a valid handle.
Regarding ExitProcess, the MSDN library has this to say:
[quote]
Exiting a process causes the following:
1. All of the threads in the process, except the calling thread,
terminate their execution without receiving a DLL_THREAD_DETACH
notification.
2. The states of all of the threads terminated in step 1 become
signaled.
3. The entry-point functions of all loaded dynamic-link libraries
(DLLs) are called with DLL_PROCESS_DETACH.
4. After all attached DLLs have executed any process termination
code, the ExitProcess function terminates the current process,
including the calling thread.
5. The state of the calling thread becomes signaled.
6. All of the object handles opened by the process are closed.
7. The termination status of the process changes from STILL_ACTIVE
to the exit value of the process.
8. The state of the process object becomes signaled, satisfying any
threads that had been waiting for the process to terminate.
If one of the terminated threads in the process holds a lock and the
DLL detach code in one of the loaded DLLs attempts to acquire the same
lock, then calling ExitProcess results in a deadlock. In contrast, if
a process terminates by calling TerminateProcess, the DLLs that the
process is attached to are not notified of the process termination.
Therefore, if you do not know the state of all threads in your
process, it is better to call TerminateProcess than ExitProcess. Note
that returning from the main function of an application results in a
call to ExitProcess.
Calling ExitProcess in a DLL can lead to unexpected application or
system errors. Be sure to call ExitProcess from a DLL only if you know
which applications or system components will load the DLL and that it
is safe to call ExitProcess in this context.
Exiting a process does not cause child processes to be terminated.
Exiting a process does not necessarily remove the process object from
the operating system. A process object is deleted when the last handle
to the process is closed.
[/quote]
Clearly, you will have problems cleaning up if you exit before
notifying the dialog or a thread that the parent is terminating.
http://flounder.com/workerthreads.htm
I haven't seen Joe in the news groups for over a year now. Either he
got busy or he got sick, I have no idea. Perhaps he got sick of
Usenet.
wrote:
Joe Newcomer's site, http://flounder.com has some excellent tips about
thread messaging and dialog boxes. While mostly MFC-focused, many of
the principles are applicable to the Win32 API, especially about
creating threads suspended and only resuming them from the main thread
once CreateThread has returned a valid handle.
Regarding ExitProcess, the MSDN library has this to say:
[quote]
Exiting a process causes the following:
1. All of the threads in the process, except the calling thread,
terminate their execution without receiving a DLL_THREAD_DETACH
notification.
2. The states of all of the threads terminated in step 1 become
signaled.
3. The entry-point functions of all loaded dynamic-link libraries
(DLLs) are called with DLL_PROCESS_DETACH.
4. After all attached DLLs have executed any process termination
code, the ExitProcess function terminates the current process,
including the calling thread.
5. The state of the calling thread becomes signaled.
6. All of the object handles opened by the process are closed.
7. The termination status of the process changes from STILL_ACTIVE
to the exit value of the process.
8. The state of the process object becomes signaled, satisfying any
threads that had been waiting for the process to terminate.
If one of the terminated threads in the process holds a lock and the
DLL detach code in one of the loaded DLLs attempts to acquire the same
lock, then calling ExitProcess results in a deadlock. In contrast, if
a process terminates by calling TerminateProcess, the DLLs that the
process is attached to are not notified of the process termination.
Therefore, if you do not know the state of all threads in your
process, it is better to call TerminateProcess than ExitProcess. Note
that returning from the main function of an application results in a
call to ExitProcess.
Calling ExitProcess in a DLL can lead to unexpected application or
system errors. Be sure to call ExitProcess from a DLL only if you know
which applications or system components will load the DLL and that it
is safe to call ExitProcess in this context.
Exiting a process does not cause child processes to be terminated.
Exiting a process does not necessarily remove the process object from
the operating system. A process object is deleted when the last handle
to the process is closed.
[/quote]
Clearly, you will have problems cleaning up if you exit before
notifying the dialog or a thread that the parent is terminating.
http://flounder.com/workerthreads.htm
I haven't seen Joe in the news groups for over a year now. Either he
got busy or he got sick, I have no idea. Perhaps he got sick of
Usenet.
R.Wieser
Mar 29, 2013, 7:04:22 AM3/29/13
to
Hey Geoff,
> Joe Newcomer's site, http://flounder.com has some excellent
> tips about thread messaging and dialog boxes.
Thanks for the link. Thats a *lot* of info there, not even sure where I
should look for info on my particual problem (if it, in fact is one).
> Regarding ExitProcess, the MSDN library has this to say:
I seem to remember having read read that. I must have forgotten about it
contains stuff that I can't verify, and thus looses all meaning to me.
I mean, what does (in #2) "the threads terminated in step 1 become
signaled." mean ? Signalled how ? What does the thread do with that
signal ? Or is it simply ment as a state (like with an Event) ? I think
so, but can't be sure. Can I see/check that state ? Alas, too many
questions (and too little answers in the text) for me to, with any kind of
confidence, interpret the information provided in it.
> Clearly, you will have problems cleaning up if you exit
> before notifying the dialog or a thread that the parent
> is terminating.
That was what my question was all about. I can do that "the process is
going to terminate, bail out!" notification by hand, but was wondering if I
overlooked something the OS would maybe do for me automatically. It looks
like it doesn't.
<snip link to workerthreads>
[quote]
"Worker threads and the GUI II: Don't touch the GUI
Why?
Because you can get into a serious deadlock situation."
Funny, that was what happened to me and why I needed to move a dialog into
its own thread, and the reason of me *again* becoming aware I did not quite
know how a closing process/main thread dealt with closing its child threads.
The problem is that the main thread *could* terminate in an unexpected way
(illegal memory access, or me force-closing the app because it becomes
unresponsive. Stuff like that), and that the above mentioned dialog also
writes to a file (which it keeps open for its own lifetime). Although I
can't say I've ever had problems with the file not closing correctly (most
likely the OS doing some (very welcome) cleaning-up) when my app wasn't
closed the normal way I really did/do not like not knowing what
happens/having any control over it.
> I haven't seen Joe in the news groups for over a year now.
I just did a quick google on him, and I must say, an impressive
track-record.
> Either he got busy or he got sick, I have no idea.
> Perhaps he got sick of Usenet.
He seems to be busy with his own company, and I know that that can be a
large time-drain.
Thanks for the info. I have to put some time it it to read it/the
important bits and digest it.
Regards,
RudyWieser
-- Origional messsage:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws
jgeal8p7r5bf3dr8l...@4ax.com...
> Joe Newcomer's site, http://flounder.com has some excellent
> tips about thread messaging and dialog boxes.
should look for info on my particual problem (if it, in fact is one).
> Regarding ExitProcess, the MSDN library has this to say:
contains stuff that I can't verify, and thus looses all meaning to me.
I mean, what does (in #2) "the threads terminated in step 1 become
signaled." mean ? Signalled how ? What does the thread do with that
signal ? Or is it simply ment as a state (like with an Event) ? I think
so, but can't be sure. Can I see/check that state ? Alas, too many
questions (and too little answers in the text) for me to, with any kind of
confidence, interpret the information provided in it.
> Clearly, you will have problems cleaning up if you exit
> before notifying the dialog or a thread that the parent
> is terminating.
going to terminate, bail out!" notification by hand, but was wondering if I
overlooked something the OS would maybe do for me automatically. It looks
like it doesn't.
<snip link to workerthreads>
[quote]
"Worker threads and the GUI II: Don't touch the GUI
Why?
Because you can get into a serious deadlock situation."
Funny, that was what happened to me and why I needed to move a dialog into
its own thread, and the reason of me *again* becoming aware I did not quite
know how a closing process/main thread dealt with closing its child threads.
The problem is that the main thread *could* terminate in an unexpected way
(illegal memory access, or me force-closing the app because it becomes
unresponsive. Stuff like that), and that the above mentioned dialog also
writes to a file (which it keeps open for its own lifetime). Although I
can't say I've ever had problems with the file not closing correctly (most
likely the OS doing some (very welcome) cleaning-up) when my app wasn't
closed the normal way I really did/do not like not knowing what
happens/having any control over it.
> I haven't seen Joe in the news groups for over a year now.
track-record.
> Either he got busy or he got sick, I have no idea.
> Perhaps he got sick of Usenet.
large time-drain.
Thanks for the info. I have to put some time it it to read it/the
important bits and digest it.
Regards,
RudyWieser
-- Origional messsage:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws
jgeal8p7r5bf3dr8l...@4ax.com...
R.Wieser
Mar 29, 2013, 7:23:46 AM3/29/13
to
Jeroen,
> I've taken a long, hard look deep inside myself, and concluded
> that this discussion is definitely not worth my time.
Your choice.
Too bad that you are quite willing to deal critisism to others (me), but
have little intention of responding to some you get yourself ...
> Especially since it's obvious it will never end until one of us
> gets tired. So I'll stop right there.
Well, in my previous reply I already suggested we should leave it be, so I
guess this thread has come to an end (no pun inteded. If I would have
wanted to make one I would say it didn't terminate graciously :-) ) .
Regards,
Rudy Wieser
-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
51549ed0$0$6899$e4fe...@news2.news.xs4all.nl...
> I've taken a long, hard look deep inside myself, and concluded
> that this discussion is definitely not worth my time.
Too bad that you are quite willing to deal critisism to others (me), but
have little intention of responding to some you get yourself ...
> Especially since it's obvious it will never end until one of us
> gets tired. So I'll stop right there.
guess this thread has come to an end (no pun inteded. If I would have
wanted to make one I would say it didn't terminate graciously :-) ) .
Regards,
Rudy Wieser
-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
0 new messages