I like the simplicity of the subclass-it-and-forget-it approach, and it does seem reliable enough, but the logic of it just doesn't seem trustworthy to me. Of course you can't do it in a main program because there has to be a wait loop somewhere keeping everything going, but in a loaded library it can just sit and wait because the main program has that. But - and this is what bothers me - If you click the menu item and bring up the control panel window, then close the main window, what exactly is supervising the orderly shutdown of the control panel window? In my threaded approach, I'm managing all that but in the subclass-it-and-forget-it version, is it safe to just chop its head off when it might be in the middle of something? I mean, there's nothing in this particular app that would be time-consuming in the message-handling of the control panel window, it's going to be sitting waiting for a message in most if not all cases, but in a larger app there might be more going on. A sudden death might just not be very clean. I just feel safer if I've got my bases covered.
Shouldn't be the case imho. Also, consider this:..having a dll throw up it's own GUI in a separate thread is perhaps not a good idea and this will very likely impinge on some PB internals!
Though I'm one of PureBasic's nocturnals
I never would touch its internals
It's for my own sake
my code would soon break
'Cause language updates are eternal.
Ok, I'm going to bed now.
[edit] I'd like it if a team member would weigh in on this. I don't want to be casting aspersions on CallFunction or threadsafety if my coding is actually at fault.