Any interest in event-driven keypresses?

I'm real-time trading on very fast charts (NQ on 5/10/15 sec) and I've come to realize that using the Parameters windows to turn on/off something on my charts is too slow, distracts from trading focus.

Using GetAsyncKeyState() doesn't work that well because it's all a timing issue of when you press the key down and when the AFL is looking for the keypress. So, you can end up having the visual go on then off again rather than an intended toggle. However, it is what I'm using now and I do get the flaky effect of having to time my keypress to get the toggle change to "stick" in the state I want. Note, I do use shift-left-mouse-click to move a target and stop around on the chart in a real-time chart and that works well because the shift key (detected with GetAyncKeyState()) is always going to stay down while the mouse click is an event.

If there were a way to detect a keypress like the way GuiGetEvent() works (i.e., event-driven notifications), then key combinations could be captured once and reported to the user, regardless of when the actual event occurred. Then, a keypress could be detected for reliable state toggles.

Is this type of thing of interest to anyone else here?

I dont know if this will help you but for a kind of trading system, i had a few permutations that i needed to switch alot.
If they are not many, you can group them and use each for a specific chart sheet. Then all you have to do is just switch between chart sheets without doing anything else.

Unfortunately, my custom "hotkeys" would be related to on-chart trading as well, like pressing the L key to set the mode for the next left-shift-click to enter long, S for short, X or ESC key for exit a trade, C for cancel, etc. It would all work beautifully if the keypresses arriving were events.

Right now, I do have Gui Buttons to do these types of things, but that still means I have to take the time to move my mouse over the button to turn it on/off and the screen dimensions these days are pretty large. Look at a 5/10/15 sec NQ futures some time...pressing keys to enter trading modes / toggle events instead of clicking buttons some screen distance away from where you're really focused (current price) does make a difference.

I realize though that I'm in a very very small minority of traders who use Amibroker. I have no need for backtesting, only real-time trading. I already know what works in discretionary real-time trading. So it changes one's perspective on what is important when interacting with a stock/futures chart.

What I should do is put together a basic template of the code I created to trade in real-time directly from a chart, document it and post it. You have to experience it directly in a live market to know what would improve your reaction time.

1 Like

I can add a feature / function that would trigger refresh (formula execution) on defined key press, something like RequestKeypressRefresh( "LSXC" ); and it would execute your formula if given key is pressed.

Please note however that in Windows keys are sent to FOCUSED window (so only ONE chart pane, currently having focus) would receive them.


Nice! And there would be some other function call to know which key caused the refresh?

Anything that works that allows you to have to do as little extra coding as possible is fine by me. What I like about this is that if I know which key triggered the refresh then I can still call GetAsyncKeyState() to find out if the Shift, Ctrl or Alt key had been pressed at the same time (e.g., Ctrl-L, Shift-L or Alt-L, etc.) because those modifier keys would be in a steady state of detection within that same refresh, expanding the combination of possibilities to setup other modes of operation.

Alternative solution (working NOW), is just to have buttons with KEY ACCELERATORS.
You create key accelerator by adding & character on key name on buttons.
So if you create button with name "Place &order" then letter "O" will be accelerator equivalent to pressing the key. If you do SetOption("GUIEnableKeyboard", True); and create buttons with accelerators, you will receive Button DOWN events when you press corresponding keys on your keyboard.


Example code for key accelerators in GUI:

idMyFirstButton = 1;
idMySecondButton = 2;

function CreateGUI()
     GuiButton( "&Enable", idMyFirstButton, 10, 60, 100, 30, notifyClicked );
     GuiButton( "&Disable", idMySecondButton, 110, 60, 100, 30, notifyClicked );

function HandleEvents()
    for ( n = 0; id = GuiGetEvent( n, 0 ); n++ ) // get the id of the event
         code = GuiGetEvent( n, 1 );

         switch ( id )
             case idMyFirstButton:
             // do something
            Say( "Pressed first button" );

             case idMySecondButton:
             // do something else
            Say( "Pressed second button" );


SetOption("GuiEnableKeyboard", True );

Note that there is one quirk in how it works because it needs a FOCUS to be on button (any button). Will check this to allow focus also in parent.


"Will check this to allow focus also in parent." (great!)

And another way to make this work when you want to use a letter for a button where the letter is NOT part of the name is to create a completely transparent button somewhere I would never click a mouse on the chart and have that button contain the letter with the '&' and its id will do the same intended functionality. The extra button could do the GuiSetCheck() on the "real" visible button so I get the visual feedback of what's going on. Sure, it's a little extra AFL code, but certainly plenty fast.

Anytime I can get some needed functionality with the least amount of effort on your part makes me happy.

I checked and things are more complicated than initially thought. Keypresses can't be passed entirely to Gui controls because then global accelerators won't work and keyboard navigation of selector line. In one of earlier beta versions Gui controls took over and this resulted in many complaints from users that they can't use arrow keys in chart to move selector line. Arrow keys unfortunatelly are also used for GUI control navigation therefore focus is used to differentiate between control navigation and selector line navigation.

I think it would be safer to add key down notifications separately and independently from what Windows is doing because Windows inner workings can't be modified and often are source of problems (since you can't do anything about what Windows does internally). I will probably add a function like GuiSendKeyEvents and you will get keystrokes as events via GuiGetEvent. That would be independent from buttons.


This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.