> Aha yes you're right, I didn't know about > PostThreadMessage(), I thought > you were talking about sending a 'window message' to a > window. However > after reading the documentation on PostThreadMessage() I must > conclude > that it doesn't really change the point I made: the thread > still has to > have a message queue.
Well, the point you made in the message I replied to was that you thought you needed an HWND for the job, and I said you just need a thread ID, and that should be the minimum info even with porting in mind. Or at least, that's what I thought. :-) > While theoretically it's not impossible > to port it > to other platforms, it's still a significant amount of work > to implement > the whole message queue idea on another platform. I don't think it's that difficult. A simple std::queue to which access is synchronized is all you'll need... > It also > looks to me as > if the gtk equivalent of PostThreadMessage() would be the > g_idle_add() > that I mentioned before, with the slight difference that > functions added > with g_idle_add() would only be executed when there are no other > messages in th gtk event queue, while PostThreadMessage() > would inject > them into the windows event queue. I don't know how you call that difference 'slight'. It can change program semantics IMO. You'd better watch out before adapting an idea like idle processing. I think a simple queue would do a better job for you. > Thanks for pointing out this function to me; I think I can write an > abstraction layer that would hide the differences between > g_idle_add() > and PostThreadMessage() so that those parts can go into the > platform-specific parts of the program, along with the gui > stuff. I'll > still have a problem when I decide to make a console frontend What's different in it with a GUI version that makes your work difficult? > but hey, > in Dutch we have saying 'he who then lives, then worries' ;) That's a very nice expression. I liked it. :-) > Again thanks for all in the replies to this thread; I have a better > understanding of how things (in particular threads) work now. > Now all I > have to do this weekend is test whether that understanding is > enough to > make my program work :) You're welcome. Shoot us if you have more questions (with your questions please, not with your hopefully not loaded gun!) ;-) Ehsan
