April White: > 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.
isBuilding needs to be known to the job queue. I think what it needs is a way for a job to be marked as a building job and when a building job succeeds, the IDM_FINISHEDEXECUTE message to the UI thread includes a parameter (1=build succeeded, 0=not a build or build failed) which is then used to set the isBuilt flag. > 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? I mean in the SciTE code, its reasonably easy to see that ExecuteOne and ProcessExecute are always in the tool thread, but AddCommand and related may now be in either thread and so when examining the code you need to be thinking about whether ParametersDialog (for example) can safely be called on either thread (or both simultaneously) or whether it needs to be protected from being called on the tool thread. > 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. I thought you might have been thinking of posting the IDM_JOBS as slightly looser: it would also make it easier to queue up both halves of a build and go before starting their execution so there would be less cases to cope with like the build finishing before calling AddCommand on the run. Neil _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
