lowlevel.library problem??

I am experiencing werid behavior from lowlevel.library's GetKey function:



Try assembling and running the above code (works with PhxAss). First time you run, it will write a line of 0's until you press a key. If you press ESC it will exit. But now the strange thing: The key you last pressed will get "stuck", even across runnings, so the next time you run it, it will exit immidiately with 0x45. I don't think this behavior is intended.

Also I have tested the QueryKeys function, and it doesn't seem to work at all...

Any enlightened comments are welcome!

The debug_buffer is too short. You reserve 10 bytes but write 12 bytes (0x12345678, lf, 0). For me it prints two lines and then crashes. It does not crash if I comment the jsr debug_write_ulong and it works correctly if I increase the buffer to 20.

@thomas

I have tried to set the size of the debug buffer to 20, and it doesn't change the behavior of the code at all, it still exits the second time with a value of $45.

Amiga model?
OS version?
lowlevel.library version?

Quote:

SAM-flex
OS4.1upd3
lowlevel.library 52.3

And yes I have also tried removing the debug output entirely.

EDIT: And I have a standard non-wireless Apple keyboard (USB).

Ok, I tried WinUAE and there it works correctly. On OS4 (A1XE) it does what you say.

If you hold down the Esc key before the second run and lift it before the first message appears, the program continues with 0xff until you press Esc again.

So it seems like lowlevel.library only records events while a program is using it. As you leave the program when Esc is pressed, it does not recognise the release of the key.

As with all libraries, the code contained within it runs on the callers context. So if the calling program has quit, then there's no caller left to call the vector again to clear the key press.

Perhaps exiting on ESC up rather than ESC down might be a better option.

Simon

The function is documented to return the currently pressed key. It does not say that you need to keep polling until no more keys are pressed. It also says nothing about the maximium time between calls.

This means the function needs to return the current keyboard state even if it is called only once. How this is implemented is up to the maintainer of the library, not of the application programmer. If the library does not recognise key-up events after the application ends (or if the application is busy), this clearly is a bug.

I must agree with thomas, I think this is clearly buggy behavior, first of all because it doesn't do what the autodocs describe, and it doesn't have the same odd behavior on classic amigas. If the current behavior is "intended", it should be at least documented as such in the docs.

@Alfkil & Thomas
If someone could write a little C program to demonstrate the problem behaviour, then I could officially report it.

I cannot verify if it does the same because I am not sitting at my A1 right now, but this is basically the program of Alfkil:

@thomas
Compile your exampe on peg2/os4u3, like this:
Quote:

And its works a bit buggy looks like indeed.. Sometime works, sometime not. I.e. i run it from shell, then press "esc", it draw some character [ in the shell, then backspace, and sometime i have 0x000000045 and exit, but sometime just not. Sometime it exit from first try of esc/backspace, sometime only on 4-5 time.

@kas1e

I think the problem is with the dos function Printf. If you insert a #include <stdio.h> and change the P to a p (notice the lower caption), it should work as expected.

EDIT: Oh and the n in the end of the first printf argument should be a \n!

Printf (with upper case P) ist just fine.

You need to understand that lowlevel.library does not capture input. It just returns the state of input devices at a very low level. It does not influence the input stream in any way.

So if you press any key while the CLI window is active, the key will be printed into the window and output is stopped. In order to continue output you have to delete the printed keys. That's the same with all non-dead keys on the keyboard.

@thomas

Yes you are right, I don't know what I was thinking...

@thread

Is this still relevant?

@alfkil

Yes I think so, had make work around in Amos Kittens, becouse key up press was sent to the wrong window (ASL Window), not the window key press down press was sendt to..