Hello,
Ehsan Akhgari wrote:
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. :-)
Well yes I did think I'd need an HWND, but what I tried to say was that I'd still need a message queue, albeit without an HWND in case of the PostThreadMessage approach. So my remark that that approach wouldn't be portable changed from needing a HWND to needing a message queue - but both with the same effect.
I don't think it's that difficult. A simple std::queue to which access is synchronized is all you'll need...
Maybe I overestimate how complicated a message queue is, but AFAIKT there would still be a need for something that would check the queue periodically. Now on windows there are OS primitives (at least that's how I always looked at them) like the GetMessage/TranslateMessage/DispatchMessage loop that block when there are no messages waiting - an efficient solution. With a home-brew queue I'd need to set a timer that would check the queue every once in a while (correct me if I'm wrong).
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.
For some cases it could indeed change the program semantics, but I doubt that it would make a difference for my purpose (updating the screen); if I would use my home-made idle functions for something else than window updating I'd probably have to make the two work more alike.
What's different in it with a GUI version that makes your work difficult?
Well the absence of a message queue. Like I said above, maybe I overestimate the difficulty in writing one for a non-gui program, but for the two gui environments I'm supporting I have access to the message queues those environments provide while for a console version I'd have to write my own (or come up with a whole other mechanism).
cheers,
roel
