Ruby UP/Down Arrows

[DaveyBoy]

Hi Folks

I wish to use the up/down arrow keys to move a selection up or down in a list. It seems that ruby doesn't accommodate key captures very easily. I've searched the entire internet ( ) and only found a couple of suggestions which I can't get to work.

So I decided to experiment (as you do).

It seems that the isKeyPressed method only responds when an event is taking place, ie a mouse click or in the 'solution' I've come up with, a trigger event (specifically a clock ticking).

Here's what I have so far:

Keypresses.fsm

(456 Bytes) Downloaded 1052 times

Only problem so far is that it doesn't respond instantly as nine times out of ten the key will be pressed in between 'ticks'. (I don't want to use a fast clock to keep the CPU load down)

Does anyone have any suggestions to improve or is there a better way to do this?

If not then hopefully this may be useful to someone

Thanks in advance
Dave

[tulamide]

Actually the continuous event calling is an interesting hack. The key press method was intended (as you already guessed), only for checking their state during mouse events.

Flowstone would have trouble if it gave up keyboard control and handed it over to Ruby, so that will never happen. But you can access the Windows API from Ruby (through user32.dll, look at user manual, chapter 8 for more details). The Windows API supplies methods to get key states at any time (and asynchronously, so no interference with Flowstone).

I know this is just a tip that points in the right direction, rather than a working solution, but hopefully you can make it from here?

[Spogg]

Here is a simple way to achieve what you’re looking for (I think).

Cheers

Spogg

[DaveyBoy]

Thanks for the hint Tulamide, I thought there must be a way.

More experimenting now

Thanks again T

[DaveyBoy]

Hi Spogg

You must have posted while I was replying to Tulamide

Thanks for that.
Yes that is what I'm looking for but I specifically want to do it with Ruby and hopefully without any clocking.
I am trying to do everything Ruby only (as far as is practically possible).

Been doing this for a couple of years now and I don't think I'll ever stop learning. How are you getting along with Ruby so far?

[Spogg]

Hi DaveyBoy

I tend to take a pragmatic approach with all things, so while it may be possible to achieve it in Ruby I think green can be just as good for some applications. So, in my view, if I just wanted to use the up/down keys I would personally do it the easier way and feed the bools into a RubyEdit. But if this is part of learning Ruby, that’s a different matter of course.

For MIDI, complex equations and functions, time-critical stuff and where triggers matter, I think Ruby is excellent and the best choice. Having said that we now know that MIDI processing in Ruby can have a large CPU impact (as per Adam).

I’ve got to a point where I understand Ruby well enough to be able to know when it’s a good idea to use it. But I have to return to my notes and the documents to refresh my memory. It was well worth the effort I put in, because I now have access to another powerful tool in FS, even though I’m far from fluent.

Cheers

Spogg

[tulamide]

Hi DaveyBoy

I tend to take a pragmatic approach with all things, so while it may be possible to achieve it in Ruby I think green can be just as good for some applications. So, in my view, if I just wanted to use the up/down keys I would personally do it the easier way and feed the bools into a RubyEdit. But if this is part of learning Ruby, that’s a different matter of course.

For MIDI, complex equations and functions, time-critical stuff and where triggers matter, I think Ruby is excellent and the best choice. Having said that we now know that MIDI processing in Ruby can have a large CPU impact (as per Adam).

I’ve got to a point where I understand Ruby well enough to be able to know when it’s a good idea to use it. But I have to return to my notes and the documents to refresh my memory. It was well worth the effort I put in, because I now have access to another powerful tool in FS, even though I’m far from fluent.

Cheers

Spogg

I think, there is some misunderstanding here. What DaveyBoy programmed can be described a a ticker that runs a KeyPressed prim. Sounds familiar? Because it is, you just offered in green what he already did in Ruby. But that's not what he's looking for. Why?
Because of the ticker. The Ticker100 prim runs as fast as possible (never really 100 times, but way higher than 25), probably around 40 to 70 times per second. So this little function, that will only be used a fraction of the plugin's running time, is constantly running at 50 tps. That's not very effective. It is even stressful for the schematic, especially if this won't be the only thing that's run with a ticker prim. To cut down on CPU time (it is more about time that's not available for other tasks, rather than acutal load), BaveyBoy created the same principle in Ruby, but reduced the amount of ticks per second drastically. That's good for the schematic, however, now the problem arises that the keypress function only recognizes what is pressed exactly when this function/prim is called. (In the case of your example, btw., it actually fires dozens of booleans, you just don't notice, because nothing, the boolean nor the graphics, changes.)

So what DaveyBoy instead is looking for is called a "callback function" in the programmer world. The system already checks all keys and the mouse regularly, no need for us to mimic its behaviour. Instead let us just ask the system to call us, whenever a key is pressed. We then just react to an event, instead of this continuous-loop mechanism. And that's really effective!

Something like that already exists. It is embedded in the window structure, which each open window represents. The one with the focus automatically gets messages about mouse behaviour and key states. Flowstone uses this, and with the help of user32.dll, DaveyBoy can use it as well. I'm not saying it is a simple task programming-wise, but for a sophisticated project it is worth it!

[KG_is_back]

I did a quick research into user32.dll. There is a function called "GetAsyncKeyState". It checks whether key is pressed OR WAS pressed since the function was last called. That would allow you to never miss a keystroke regardless of how often you check.

As tulamide mentioned, making a code that automatically executes on arbitrary keystroke is currently not possible. One possible hack is to create edit box (which to windows counts as new separate window) and have code executed via "editChanged" method in ruby. However, that one only works when the actual text in the edit box changes - ie. it only detects characters (and backspace/delete keys if the text and cursor happens to be aligned properly). It also severely messes with the redraws, because the flowstone window is not in focus during editing.

[DaveyBoy]

I've been experimenting with the GetAsyncKeyState and GetKeyState functions. Got them both working (after a lot of googling) but only with a ticker or clock running, so no different to my original hack really.

So are you saying that with a callback function it is possible to get realtime keypresses without tickers or clocks? . . . this would be ideal.

I've obviously still got a hell of a lot to learn with this but I'll persevere.

Thanks for the help so far guys

[tulamide]

I've been experimenting with the GetAsyncKeyState and GetKeyState functions. Got them both working (after a lot of googling) but only with a ticker or clock running, so no different to my original hack really.

So are you saying that with a callback function it is possible to get realtime keypresses without tickers or clocks? . . . this would be ideal.

I've obviously still got a hell of a lot to learn with this but I'll persevere.

Thanks for the help so far guys

I hesitated to point to GetAsyncKeyState, because it is a system message, not a window specific message. That means, if there is another process (or application) running that also uses asyncKeyState, it might get the message before you had a chance to get it. After it had been called it clears its buffer, so for the next one there is no last key anymore, just the current state. However, when you test it and don't run any other applications, it should at least sometimes work. And then it works even with a clock only running 4 times per second, which would be an improvement.

Yes, there is an event mechanism that informs the window structure of a keydown event. WM_keydown is called for that. It is basically a variable holding information about which key was pressed. So the code would need to do something like this:

Code: Select all

PSEUDOCODE!!!
if WM_keydown == up_arrow
  #execute your list scrolling
elsif WM_keydown == down_arrow
  #execute your list scrolling
end

B8ut to get to that point you have to hook into the window structure. Therefore you need a window handle (but in most cases NULL [=all bits off] points to window with the current focus, so that's the Flowstone window. Also, there's GetActiveWindow(), which returns a handle to the window that's associated with the originator that called the function (here again the Flowstone window), even if it is not in the foreground.

With the handle, you can then setup a callback function known as WindowProc (you can choose whatever name you like for it). Here's a link:
https://msdn.microsoft.com/de-de/library/windows/desktop/ms633573 (uMsg will receive the WM_keydown)
I think chapter 8 of the manual also covers setting up Windows callback functions in Ruby.