Page 1 of 1

ProcessEditorEventW suggestions

Posted: Tue 06 May, 2014 11:56
by pepak
Hi!

For my plugins, I would find it quite useful if the ProcessEditorEventW function got expanded. Specifically, I need:

- EE_CANCLOSE, which would get called just before EE_CLOSE and with the same arguments. If it returned TRUE (the default value), then normal closing would commence, otherwise the closing would be aborted and the edited file would remain in the editor.

- Split EE_SAVE into "EE_BEFORESAVE" and "EE_AFTERSAVE".

- I don't need that yet, but it would follow that EE_LOAD would also have a BEFORE and AFTER variant.

Any chance of these functions being implemented? I expect the CANCLOSE event should be simple enough. Thanks.

Re: ProcessEditorEventW suggestions

Posted: Tue 06 May, 2014 13:54
by Skirda
==> mantis

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 13:32
by John Doe
Consider another approach: what if we had some special option for Editor function?
There are flags like EF_NONMODAL, EF_IMMEDIATERETURN, etc.
Maybe you need new flag EF_RETURN_BEFORE_QUIT?

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 13:51
by pepak
If I understand it correctly (maybe I don't), then it would not be suitable for my needs. How would it behave? In my opinion, it would only work for modal editors, and I can achieve much the same result for modal editors already.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 13:56
by John Doe
It should behave like modal but return BEFORE quit, so you will get access to final editor content.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 13:59
by pepak
Then I understood correctly. No, that would not help me at all - I can already do that for modal editors. I need to solve the task for non-modal editors.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:04
by pepak
In fact, I can do it even for non-modal forms, but it's somewhat ugly. A EE_CANCLOSE event would solve my issues much better.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:20
by John Doe
It's interesting. How you do it for non-modal editors?

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:24
by pepak
When I create a non-modal editor, my plugin stores some state information to a list. When a EE_CLOSE event arrives, I first check whether it is my editor which is getting closed, and if it is, I perform some operations before I allow ProcessEditorEventW to quit. Check my new DirSync for details.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:26
by pepak
My problem lies not in detecting the quit and doing something at the time, but in preventing the quit completely. The only way I can do it now is to copy the editor's file to a new name and open a new editor in ProcessEditorEventW. It works, but it is ugly.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:30
by John Doe
Why do you need to prevent quit?

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:34
by pepak
Suppose that I have a file in the editor. I want to provide a function which would filter some lines (think grep). Then the user could edit the filtered lines and eventually quit the editor. At that moment I would recognize that a filter was in effect, so instead of actually quitting I would apply the filtered lines to the original file and show the original file again.

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:43
by John Doe
When user hits F10, doesn't he want actually to quit?

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:44
by pepak
Not if he uses DirSync :-)

Re: ProcessEditorEventW suggestions

Posted: Wed 14 May, 2014 14:59
by John Doe
Then you should not complain about ugliness of your workarounds :-)