Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes.

Nikolay Nikolov wrote

Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes.

It was changed in revision 3443, whose log message says:

r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths:
M /trunk/fv/app.pas
M /trunk/fv/drivers.pas
M /trunk/fv/validate.pas
M /trunk/ide/fp.pas
M /trunk/ide/fpide.pas

* Video and keyboard initialization spaghetti organized and hopefully fixed.
- Remove useless function from validate.pas

Maybe Daniel knows.

Jonas

Op Sun, 16 Aug 2009, schreef Jonas Maebe:

In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications.

With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized.

Daniël

This is all cool, but IMHO DoneKeyboard should also be called in the ExitProc to clean things up in case a runtime error occurs, since then the TApplication destructor isn't (usually) called. Is there a reason not to do that? Calling DoneKeyboard twice on normal exit should be safe, as it checks a flag and does nothing when you call it the second time.

Op Sun, 16 Aug 2009, schreef Nikolay Nikolov:

I can see the issue with abnormal program exits, but I disabled it because calling it twice had unintended effects. So we need to verify we don't break anything.

Daniël

Daniël Mantione wrote

I can see the issue with abnormal program exits, but I disabled it because calling it twice had unintended effects. So we need to verify we don't break anything.

Well, I can think of 2 thing that could go wrong:

- DoneKeyboard is called _after_ DoneVideo (not before) in TApplication.Done. I'm not sure if the order matters. We can switch them in the Drivers unit ExitProc also.
- If DoneKeyboard blows up with a run time error, during a normal TApplication.Done call, then the ExitProc of the Drivers unit will call DoneKeyboard again, which in turn will call SysDoneKeyboard again, because the previous SysDoneKeyboard didn't finish and the KeyboardInitialized flag wasn't set to false. I don't know if this might have unintended side effects. This is all in rtl/inc/keyboard.inc:

procedure DoneKeyboard;
begin
   If KeyboardInitialized then
     begin
     If Assigned(CurrentKeyBoardDriver.DoneDriver) Then
       CurrentKeyBoardDriver.DoneDriver();
     KeyboardInitialized:=False;
     end;
end;

If that's the case, we can add a flag KeyboardInitialized in Drivers, add a check inside Drivers.DoneKeyboard and set it to false _before_ the actual call to Keyboard.DoneKeyboard.