Chachereau Nicolas:
I think we should decide in which way SciTE reacts when it is sent a message. I think SciTE should be raised above the other windows in some cases, like: find:, goto:, insert:, loadsession:, macrocommand:, macrolist:, menucommand:, open:, output:, replaceall:
Fronting windows with insufficient reason became such a problem on Windows that recent versions of Windows try to stop applications fronting themselves except in particular cases. SciTE should not be fronted by default for most of these commands as they damage use cases where SciTE is being controlled by a foreground application that wants to retain focus over a sequence of actions.
How strict should we be about the "closing:" message? If there are any unsaved files, and the user cancels the quit, should SciTE send a message to tell the director it didn't quit? Or should it be impossible for the user to cancel a quit when the director is closing?
There should probably be an alternative command for one or the other since it depends on the controlling application.
I don't really like the assumption that a process can only communicate with SciTE if it started it. I think a process should be able to become a director even after SciTE started.
Say you have a director application along with SciTE instances attached to it. You don't want the director to interfere with SciTE instances that you (or another director) started independently.
To achieve this, we may have to change the method we use for IPC.
Most of my thinking about the director interface was on Windows where WM_COPYDATA can be broadcast to all windows or sent to one in particular. Neil _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
