[Fixed][sug, Editor] press Escape should not immediately close

[mobius]

I feel like I or someone else talked about this before but I don't remember what was discussed.

I like having a button that can quickly terminate a program. But recently I was just in the middle of editing a level, accidentally pressed escape and it immediately quit without saving. I believe Lix has (or used to have) a feature which if you held down escape for two two five seconds or something it force quit. This is good; but accidentally pressing quickly and losing data is not.

Even pressing Alt+F4 asks you if you want to save. Which btw; should have a cancel button which it does not.

[IchoTolot]

I think you should specify in the level title that you are referring to the editor. I was a bit confused at first

So please name the topic [Suggestion][Editor] at the start to clarify the matter.

About the matter: Yes, I think asking the player if they want to save the level is always beneficial.

I would even advance this confirmation box to the "Save" function. Currently it just saves over the file without needing a confirmation, but I think this could possibly be fatal if it's an accidental click.
Example: You made an experimental change to a level that you want to discard again but accidentally press the "Save" button and you saved over your file. Also, "Undo" can't fix everything every time.

So all in all my suggestion here would be:

The "Escape exit" and "Save" function should first ask for a confirmation before executing their routines.

[mobius]

yes I mean the editor my bad. I fixed it.

I don't know if I'd go so far as to want a confirmation box on the plain save or Ctl-S function. I press Clt-S constantly in case my PC dies/power goes out etc. Not sure I feel like going through another box everytime. I haven't had any major issues in this regard. Most programs don't have this for basic Save and I think it works.

[namida]

I don't think Esc should be a quit key at all. It's too easy to accidentally hit it one too many times when exiting playtest mode. If it must be one, it absolutely needs a confirmation dialog.

[Simon]

Agree that editor should ask before discarding data (create blank level, exit program).

Esc shouldn't be a quit key: My hunch would have been that Esc deselects everything and cancels dialogs, but not exit the editor. There is Alt+F4 to quit the program (can catch this event and offer the save confirmation before exiting), and some programs offer Ctrl+Q. But Esc alone is unusual, and even though Lix has Shift+Esc to quit immediately, I consider Lix's Shift+Esc weird design and don't recommend it.

I advise against confirmation during save: I believe that would become annoying, especially when mobius hits the save function frequently. For the few occasions where you mistakely overwrite a level with rubbish, consider version control to undo the mistake. git loves text-based level formats.

-- Simon

[Nepster]

1) When I quit the editor with ESC, it asks whether I want to save the level or not (except when there is no change at all to the level, or you just created a completely new level). So please post a way for me to reproduce this bug.
2) There is a problem with adding a cancel button to the "Do you wish to save before quitting the editor?" dialog: In order to catch all ways to exit the editor (short of terminating the process), I put the relevant code on a rather late stage in the middle of closing the main window. I am not sure how I could salvage the application at that point.
So while I certainly think a "Cancel" button would be beneficial, it won't be an easy addition and therfore not something you should expect soon.
3) I am very much against a confirmation dialog for saving. No major application does this, cf. Notepad++, Open Office, ...
4) I don't like to have Alt+F4 as the only hotkey to close the application. On my laptop this results in the key combination "Alt+Fn+F4", which is way too ugly for a function like exiting the application. In addition to that, the NeoLemmix player exits on Esc, so according to "Similar applications should behave similarly", the editor should behave the same.

[mobius]

@Nepster: correction; it indeed does bring up a a dialogue, so there was no loss of save data. I must have been mistaken (or saved when I didn't remember I did) when I thought I lost data.  This was not as big of a deal as I thought. There is still a minor problem though;

Agree that editor should ask before discarding data (create blank level, exit program).

Esc shouldn't be a quit key: My hunch would have been that Esc deselects everything and cancels dialogs, but not exit the editor. There is Alt+F4 to quit the program (can catch this event and offer the save confirmation before exiting), and some programs offer Ctrl+Q. But Esc alone is unusual, and even though Lix has Shift+Esc to quit immediately, I consider Lix's Shift+Esc weird design and don't recommend it.

I advise against confirmation during save: I believe that would become annoying, especially when mobius hits the save function frequently. For the few occasions where you mistakely overwrite a level with rubbish, consider version control to undo the mistake. git loves text-based level formats.

-- Simon

I agree that Esc should deselect everything and cancels dialogs: that's what it usually does. I don't mind having a force quit key too though. I liked the lix design of holding the button down for a few seconds. That worked really well for me. I never accidentally quit and found it easy to quit quickly when I wanted to.

But currently if you're in a form and press esc it quits instead of removing your cursor from the form.  Maybe this isn't a major issue; but I'm so used to pressing escape to get out of a window or etc that I wasn't expecting the program to quit.
I guess the most important thing is: the quit dialogue box should have a cancel option.
OK then, I understand. Still this feels like a problem that may get run into now and then. A temporary solution like the hold-down key would be nice.

The heart of this problem is the same as my complaints with Lix: When using a computer for a long time you get used to a routine and custom of hotkeys and layouts and such. It take a great deal of time and effort to learn these so if you make your program different; it really stands out and people will get frustrated quickly if you break these conventions. Unless it's done really well like; imo in the case of the hold down esc key.
Antichamber is another example of a game that quits on hold down of escape key.

-------
People should stop using laptops. It seems all I'm hearing lately (in other places too) is "etc difficulty because I'm on a LAPTOP"

[namida]

Aside from recent MacBook Pros, I've never yet seen a laptop that requires an Fn+Key type combination for the F keys, that doesn't also have an option in the BIOS to revert to normal behaviour (with Fn + key then giving the alternative effect that was previously standard). YMMV, but I find that even these days when I'm not really doing much Lemmings stuff (and when I am, I rarely use the F key shortcuts anyway; I usually use middle-click for pause and the mouse for everything else on the skill panel), I use the F keys more often than most of their alternate uses, the only ones I use regularly being the volume keys.

Regarding the cancel option - this sounds like you need to revise when the editor generates this option. Essentially, it should be the first thing that happens after selecting New / Load / Exit (though in the case of Load, popping up the select file dialog first is understandable, as this seems to be the standard for many applications). This could work simply by, upon triggering one of these functions, immediately running something along these lines (using Delphi-ish code in this examples):

Code Select Expand

procedure OnClickOpen(Sender: TObject);
begin
  if not DoSaveConfirm then Exit;
  DoOpen;
end;

function DoSaveConfirm: Boolean;
begin
  if FileDoesntNeedSaving then
  begin
    Result := true;
    Exit;
  end;

  case MessageDlg('Do you want to save?', mtCustom, [mbYes, mbNo, mbCancel], 0) of
    mrYes: begin DoSave (* this procedure will ask for filename if needed, and then save the file *); Result := true; end;
    mrNo: Result := true;
    mrCancel: Result := false;
  end;
end;

In terms of running this when trying to quit the application, at least in Delphi forms have an "OnCloseQuery" event which is the key to this. One of the parameters is "var CanClose: Boolean" (might not be that actual name; what matters is that it's "var" and Boolean); the value "true" is passed to this when the event is triggered, but if it's set to false during the procedure, the application will not close - this is what you'd do on cancel.

[ccexplore]

Does NeoLemmix editor supports remapping keys?  It sounds like the crux of the problem is that ESC is overloaded to both dismiss minor pop windows of the editor, as well as quitting the entire application itself.  If key remapping is already supported then naturally, the ability for user to assign different keys for the two slightly different actions would potentially be a helpful workaround.

Requiring holding down ESC for quitting the entire application sounds reasonable if it is simple enough to implement with the current code, although I suspect it'd easier to just detect Shift+Esc or Ctrl+Q instead like Simon had mentioned.  Prompting to save before quitting sounds like is already there in some form in the program, and should be irrelevant to which key(s) were used to triggering the quit request (or at least, it should be programmed in such a way that it is irrelevant).

[Nepster]

The heart of this problem is the same as my complaints with Lix: When using a computer for a long time you get used to a routine and custom of hotkeys and layouts and such. It take a great deal of time and effort to learn these so if you make your program different; it really stands out and people will get frustrated quickly if you break these conventions. Unless it's done really well like; imo in the case of the hold down esc key.
Antichamber is another example of a game that quits on hold down of escape key.

I totally agree with you here, but there is one huge problem with not breaking user's routine: Everyone has different expectations on what should happen! For example holding down the ESC key for a second or so sounds totally silly to me. If that would be the only way to quit an application, then I certainly won't find it, become extremely frustrated and then quit by terminating the application in the Task Manager.

Regarding the cancel option - this sounds like you need to revise when the editor generates this option. Essentially, it should be the first thing that happens after selecting New / Load / Exit (though in the case of Load, popping up the select file dialog first is understandable, as this seems to be the standard for many applications). This could work simply by, upon triggering one of these functions, immediately running something along these lines (using Delphi-ish code in this examples):

I already have more or less exactly the code you wrote, and for New and Load I can (and do) call it early. That is not the problem.

In terms of running this when trying to quit the application, at least in Delphi forms have an "OnCloseQuery" event which is the key to this. One of the parameters is "var CanClose: Boolean" (might not be that actual name; what matters is that it's "var" and Boolean); the value "true" is passed to this when the event is triggered, but if it's set to false during the procedure, the application will not close - this is what you'd do on cancel.

I read now through the C# documentation and in C# it is done somwhat differently: It's not directly a parameter of the event handler, but instead the so-called FormClosingEventArgs has a property Cancel, which one can set to true. So adding a cancel button to the "Do you wish to save before exiting" dialog seems more feasible now.
PS: This design by C# is definitely rant-worthy, because is is so unexpected: In almost all other cases the EventArgs only hand data to the event handler method, but cannot be used to return info.

Does NeoLemmix editor supports remapping keys?

That's one of the features that is on my ever-growing to-do list, which however will most likely not be implemented for a while, because I just don't have time.

I think the biggest problem here is: I just love the possibility to exit the editor with just one keystroke on ESC. On the other hand I can understand that others would expect less dramatic results, and so I don't know yet how to get these two points of view together in a way that doesn't require lots of coding on my part.

[mobius]

I wasn't suggesting the hold-escape key be the only method of quitting. Alt+F4 already works as it should . I was just mentioning this as something new to me recently that came across surprisingly well to me. I like simple functions. (But no so simple that you accidentally quit, which is what happened).

Anyways, as stated, I was totally mistaken about my initial post so my major complaint/request is dropped.

[Dullstar]

Escape should not be a quit hotkey at all by default. Closing programs does not appear to be a standard feature of the escape key, at least not in Windows programs. Just testing various programs I have on my computer, most use it ONLY to dismiss dialog windows, and don't respond to escape at all when no dialog window is open. In games, it usually brings up a menu, rather than quitting outright. The most quit-happy example I can think of is Cave Story, which requires pressing escape TWICE (once to bring up a menu, second to close from that menu - the fact that hitting escape again will close the game is in large text on the menu).

If alt+fn+f4 is a problem (just press the close button with the trackpad?), then make quit rebindable to escape. But don't make it the default, because people have no reason to believe pressing escape will cause the whole program to close, because it almost never does.

[namida]

Doesn't seem this was ever resolved.

Now that I'm actually using the editor, I'm finding it very annoying, especially given the lack of a Cancel option in the popup. All it would take is for me to accidentally click "No" (thinking "I don't want to quit"), and bam, data is potentially lost. I've had a couple of close calls where I nearly lost entire completed levels this way (and yes, I should save more often; but at the same time, there shouldn't be the risk of losing it just because in playtest mode I pressed the exit-playtest-mode key one too many times), but remembered just in time that I need to click "yes, save" because the editor is exiting either way.

On a semi-related side note, the fact that the editor deletes the temp level file upon exiting compounds with that problem. I presume if the editor outright crashes, it wouldn't delete the file; but at any rate, in the event of an accidental exit, or mistakes that can't be undone by re-loading a saved file, the temporary level file from playtest provides an additional way that the level may possibly be recovered. It existing does no harm, so why not leave it?

[SQron188]

This feature actually caught me off guard when I hit Esc by accident - just yesterday, I think? I got confused initially, then figured "huh, this must be what Esc does in the editor."

It didn't affect me negatively since I save after putting down each tile/object and after changing any properties.

Esc shouldn't be a quit key: My hunch would have been that Esc deselects everything and cancels dialogs, but not exit the editor. There is Alt+F4 to quit the program (can catch this event and offer the save confirmation before exiting)

The intuitive function of Escape for me is, indeed, to cancel a dialogue window. Deselecting also sounds intuitive and sensible to me.

[Nepster]

Thanks for reminding me of this.

By popular demand, I implemented the following changes:
1) Esc does no longer quit the editor.
2) Esc does close secondary windows (like the settings or the hotkey window)
3) The do-you-want-to-save dialogue when quitting now has a cancel button

On a semi-related side note, the fact that the editor deletes the temp level file upon exiting compounds with that problem. I presume if the editor outright crashes, it wouldn't delete the file; but at any rate, in the event of an accidental exit, or mistakes that can't be undone by re-loading a saved file, the temporary level file from playtest provides an additional way that the level may possibly be recovered. It existing does no harm, so why not leave it?

There are two slightly incorrect statements in there:
1) The temp file is only for playtesting purposes. When exiting playtest mode, it already gets deleted. So usually you won't have it around when quitting the editor.
2) As long as you don't terminate the editor process, the editor will always ask whether you want to save the level or not. This even applies on any crashes (as long as Windows still reacts).
Regarding keeping the temp file: Personally I hate it when applications clutter folders with temporary files that they don't delete themselves. This especially applies to files lying around in a main folder where users will look into, as it is the case for this temp file.