I am trying to make a on-screen keyboard which can be commanded both from touchscreen and IEC code (external, remote input). I am on Codesys SP16 because of target.

So I copied VisuDialogs and added a visualization and a manager to handle IEC-side events.

I found, via Visu Dialog ST example, that an IVisualizationDialog.GetDialogInterface method exists, and it seems to work by temporarily changing visualization own IVisualizationDialog._pInterface (because when halt on breakpoint I see the referenced address change (see image 1 and 2), and every change to the local structure is immediately reflected to the dereferenced IVisualizationDialog.* members).

Then I call IVisualizationDialog.SetInterface(pInterface := ADR(my_temporary_interface_struct)), whose comment says "Copies the members from pInterface into the members of the dialog", but it seems to be a no-op: at the end of the cycle IVisualizationDialog._pInterface comes back to the value it had before calling GetDialogInterface (see image 3), and so changes are lost.

Opening the dialog with VU.FbOpenDialogExtended and passing a pointer to an interface structure does not work, neither by the combo GetDialogInterface/SetDialogInterface nor by changing members of the structure passed (and then calling IVisualizationDialog.Update() or not).

Please attach a project archiv

Here you are.
It is a "work in progress" and needs a LOT of polishing (from supporting multiple keypads to a general reorganization).

In the PLC_PRG there is a small test/explorative project where you have variables for simulating a push, rolling around and opening the window from IEC code (or not).

The interface will be overwritten each cycle.

Currently a bit confused why you want to set the interface yourself.
Whats wrong with the one used by the visualization?

Also it is not clear for me why you want to open the dialogue both via an input and via VisuUtils.
You can select the simplified dialogue in the visu manager.

Best regards,
Marcel

Could you maybe help me understand exactly what you are trying to do?
If I understand you correctly, you try to enter values into the keyboard via IEC?
Why do you have this requirement and what is the goal you are trying to achieve?

Best regards,
Marcel

The keyboard must be controllable both by touchscreen and by CAN keypad (similar to the Grayhill one, with a wheel and some keys).

On some machine models the display does not have the touchscreen, so IEC control is the only way, on other models the user could open the keyboard from CAN but then proceed to write by touchscreen and then confirm/cancel via CAN (or via touch).

So the "presses" can be intermixed from touch and CAN (thus there is an event queue which guarantees serialization, even if the event from IEC side come at a faster rate, like a burst of 5 events, 20 ms apart when the VISU_TASK is running at 200 ms cycle time). Also, in this way no CAN movement interferes with a direct touch press.

Either I change the local dialog store area, or I use a global store and then dialog interface is not used at all (on the TargetVisu, at most one keypad at a time will ever be present).

I would assume then that with the turn of a wheel you want to jump from a Q to a W to a E etc etc?
Also pressing a specific button on the CAN keypad will open the dialog and another one is like an Enter?

If that is the case your solution could also be to use the keyboardhandling and move the selection on each wheel turn with the selectionmanager.

Yes. But these action could be intertwined with touch actions.

I tried the stock selection example, but it "worked" only if I activated the "Standard keyboard handling" (and it did not work at 100%). Unfortunately the display own keys (some are mapped to the arrows, some to Tab, some to Enter and so on) cease to work correctly, because the keypresses are interpreted by Codesys instead of just being forwarded to the visualization (that already handles them).

If you are using a target visualization (a panel with a screen and the runtime is running on that panel) then the CODESYS IDE has no part in handling events.
This is all done by the visualization, which collects the events, passes them to IEC where the visu task handles them and then draws the changes to the screen again.

Anything special which did not work?
Yes, the selection example is controlling the keyboard handling, which you do have to activate.

I was not referring to the Codesys IDE, but to the TargetVisu runtime. The problem is that a display key is mapped as "Tab", another as "Up" and so on. This is at the OS level (Linux embedded), fixed.

So if I activate "Standard keyboard handling" and I press the key that generates a "Tab" keypress, it moves focus {instead of}/{in addition to} doing the action associated with that key in the code. Same for Up, Down, Home, End and so on. These keycodes have no special meaning attached, the manufacturer could choose to map them as F15, F16, F23, "w", "$", or any other keycode. Unfortunately it chose keycodes that clash with Codesys keyboard handling.

I did remember that selection by IEC code worked half of the time on the hardware, worked right on Control Win. On the panel pressing Up and Down with standard keyboard handling moved Up and Down, but since I do not have Left and Right movement was a bit weird (it resulted in moving diagonally to the right in a W pattern, not being able to select some keys and not being able to come back to the left part).

Oh I see, that will make things way more difficult ;D

Assuming that they display keys are mapped to a tab+enter/return (which it looks like since the action is executed), we could filter out the enter/return key.
You think that would solve the problem and you could use the normal keyboard handling?

Best regards,
Marcel

Home, End, Esc, Tab, Up, Down, Enter.

How would you do it?

For the time being I had to redirect every call to a global memory area, but I am still interested in making this work the "right" way.

Not gonna claim this is the "right" way.
But we have some challenges ahead and the right way may change ;)

You can find an example for the IKeyEventHandler. If HandleKeyEvent returns true, the key press will be dropped.

Important: Make sure to call the PRG by adding it to the "Call after visu initialization" in the visu manager.

Best regards,
Marcel

I'll look into it. Thanks.