Neil Hodgson wrote:
I've been thinking of a new approach to the 'send job message' to the
window. My initial test worked by having the AddCommand method send the
job message. This eliminates the need for individual calls to
AddCommand to send the message.
One problem with this is that code that calls AddCommand often
checks immediately if the queue is empty.
The only time I can see that code checks if the queue is non-empty is to
assign TRUE to isBuilding. I'll change AddCommand() to return true/false
indicating that something was added, eliminating the need to examine if
the queue is empty.
The parameterised command seems really confused now:
I'll try your example later this week. I knew that as soon as I altered
how jobs worked, the parameterized command was be flaky.
To make the code easier to understand, the key functions should
have comments that say which threads they can be running on.
I'm all for such a revision, but I'm a little unsure what 'key
functions' to mean. Are you referring to the functions of the jobQueue
class?
Is it safe to issue a message within the message handler?
SendMessage may be reentered but it is often an indication of
overly complex code, and there is a potential for trouble if the
message is unexpectedly crossing threads.
I want the IDM_FINISHEDEXECUTE code to activate the next job in the
queue. I can either send the appropriate message, or reposition the
IDM_FINISHEDEXECUTE code to fall into the IBM_JOBS code.
April
--
Error: Keyboard not attached. Press F1 to continue.
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
