#66 Keyboardon doesn't react

[Manfred Zindel]

While I did some wonderful experiments with mouse events, I was surprised that I couldn't run keyboardon successfully. Things I did years ago didn't run any more, but, of course, they were complicated.

But now I have only one simple problem to solve: I have a procedure which does some worl in the graphics area, and I want to start it by hitting the ESCAPE key. But everything I tried gave me no reaction and the examples in the documentation didn't do what I expected.

Now I'd like to ask for an example how I can start a procedure using the escape key. And even if the only contents of this procedure would be "PRINT "Hello, it might be useful.

[David Costanzo]

I just tested FMSLogo 8.4.0 and KEYBOARDON was able to react to the Escape key on my machine.

The easiest way to see KEYBOARDON work is to have it print KEYBOARDVALUE in its callbacks:

(KEYBOARDON [SHOW SENTENCE KEYBOARDVALUE "down] [SHOW SENTENCE KEYBOARDVALUE "up])

Here's a simple program that prints when Escape is pressed:

(KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] [])

Since you mentioned that the things you were doing were complex, it might be worth starting with just these two examples and nothing else, not even Little Helper, to see if they work on your machine.

[Manfred Zindel]

Thank you for the examples.

Nevertheless, frustration goes on.

I copied exactly the following to the commandline on two different machines (notebook and desktop) WINDOWS 11, FMSLogo 8.3.2 and 8.4.0 original.

Well, the input was echoed, but when I pressed ESCAPE, there was no reaction whatsoever. The focus was FMSLogo. I tried the same with ENTER and arrow keys, but the answer was nothing at all.

Regarding all the complicated things I did in the last days with mouse and TIMER, where FMSLogo followed orders perfectly according to the documentation, I cannot understand this and don_t know how to settle this.

I'd like to do some experiments with SOUND and we are expecially interested in explaining callbacks and asynchronous behavior to the students. So far this went pretty well, but we are interested in offering the whole stuff, especially as FMSLogo works fine and helps understanding logical thinking in times of KI promts as replacement of programming.

[Manfred Zindel]

Sorry, I forgot what I really copied. It was:

(KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] [])

[Manfred Zindel]

Good news!

We went back to our former copter project where a model copter is flying over air photos of our region controlled by arrow keys. We then implemented this unfinished project into a Little Helper environment before we put it into an archive and now managed to transfer it to the actual Little Helper successor four years later, where the development can be continued as soon as we have time for it.

So, now we can figure out why the copter works with KEYBOARDON other than our new procedures. We may be able to solve the problem.

[Manfred Zindel]

To solve the KEYBOARDON-Problem, I need to know everything about Focus in FMSLogo.

the documentation of SETFOCUS and GETFOCUS is not very clear, so I cannot be sure what to answer to the following questions:

1. Is FMSLogo the caption (title) of the graphics area or of the commander? And how is the other one, the contrary, called?
2. Are there still more possible captions. and which is the complete set?
3. Which are the consequences of setting the FOCUS to a special caption?
4. How can I find out, which focus is currently active? (There is no FOCUS? or FOCUSP.)

Although this might be of general interest - my reason to ask all this is my suspicion that the KEYBOARDON-failure I observed has something to do with focus.

[Manfred Zindel]

Now I found some answers in the description of KEYBOARDON itself:

Note the "Screen" must have focus (NOT the commander) to catch the key events. You can force this by calling SETFOCUS [FMSLogo] after you call KEYBOARDON. All the "callbacks" for the keyboard are automatically run in NOYIELD mode.

But if the Screen needs the focus, why will I have to write SETFOCUS [FMSLogo] after KEYBOARDON and not SETFOCUS [screen]?

I think, Copter works in Little Helper because there was the right focus by lucky circumstances and not intentionally.

But if FMSLogo is the caption of the commander and Screen the caption of the screen, why do I have to write "SETFOCUS [FMSLogo] after you call KEYBOARDON" and not SETFOCUS [Screen]?

[Manfred Zindel]

I'd like to make the proposal to add a link to KEYBOARDON at SETFOCUS and GETFOCUS - or to explain a little more about FOCUS at SETFOCUS and GETFOCUS.

[Manfred Zindel]

Well, here is finally the solution to the riddle::

(KEYBOARDON [IF EQUAL? 27 KEYBOARDVALUE [ SHOW [ESCAPE Pressed] ]] [])  SETFOCUS [FMSLogo]

Now it works!
But what the documentation says is that the screen should have the focus, but isn't it given to the commander by SETFOCUS [FMSLoco}?

~~~
The "Screen" must have focus (NOT the commander)
You can force this by calling SETFOCUS [FMSLogo] after you call KEYBOARDON
~~~

Who is who and what is what? Does the caption FMSLogo mean the screen or the commander, and what is the other one then?

[David Costanzo]

I'm glad you were able to solve this.

I don't know why you'd think that the Commander has the caption "FMSLogo". When it's docked, it doesn't have a caption. When TEXTSCREEN or FULLSCREEN is used, the caption is "Commander". The window that has the caption "FMSLogo" is either the overall window or the window that holds the drawing surface.

This is somewhat irrelevant because "FMSLogo" is a special case that always gives focus to the screen. This is hard-coded into graphwin.cpp:

NODE *lsetfocus(NODE *arg)
{
    ASSERT_TURTLE_INVARIANT;
    CStringPrintedNode windowCaption(car(arg));

    if (0 == wxStricmp(L"FMSLogo", windowCaption) ||
        0 == wxStricmp(L"MSWLogo Screen", windowCaption) ||
        0 == wxStricmp(L"FMSLogo Screen", windowCaption))
    {
        // special-case: set the focus on the screen
        GetScreenWxWindow()->SetFocus();
    }
    else
    {
       ...
    }

    return Unbound;
}

Your idea of adding "See Also" links for SETFOCUS/GETFOCUS to KEYBOARDON makes sense. Perhaps it also makes sense to document in SETFOCUS that SETFOCUS "FMSLogo also gives focus to the screen. I thought that would be implied, given that the window title "FMSLogo" sits right above the screen, but if it took you by surprise, it might take others, as well.