> (April) > As well, the suggestion offered by Bruce whereby the ToolMenu() method > builds one large command mode string to be passed into > DecodeCommandMode(), are there any objections to it? I have looked at it > and see some merit to it, though I would probably define and loop through > an array of command properties and equivalent mode strings, to consolidate > this new implementation. Right now there are a half dozen repeated blocks > of code that could be reduced.
You're right. I will look into that and offer a revision. If there is a function to decode the command mode string (that doesn't add to the job queue), it needs more parameters. In particular, the "save-before" value should not be stuffed into the flags. Save-before is not a queued action: the save occurs in the main thread, before the command is added to the queue, and the flag isn't needed later. So, it is cleaner to keep it separate from the flags. I had one more observation about that function (DecodeCommandMode): The parameters are pointers, not references. Was that an arbitrary choice, or were there technical / design reasons for it? I don't mind if they are pointers; but if they are pointers, perhaps the function should check for null and ignore the corresponding command.mode flags if the pointer is null. > BTW Bruce, I am not quite sure which "Execute" you are referring to. > Since Lua already has an Execute() method I thought it would be more > natural for script writers to use scite.Execute(). Within SciTE itself I > removed SciTEWin::Execute(). I was referring to SciTEBase::Execute (and SciTEWin::Execute). Cheers, Bruce _______________________________________________ Scite-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scite-interest
