IVisualizationDialog.SetInterface does not seem to work at all

2022-04-05T07:11:16.434000Z

I'll look into it. Thanks.

IVisualizationDialog.SetInterface does not seem to work at all

2022-04-04T09:01:35.124000Z

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.

Best regards,
Marcel

IVisualizationDialog.SetInterface does not seem to work at all

2022-04-04T06:22:06.534000Z

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.

IVisualizationDialog.SetInterface does not seem to work at all

2022-04-04T05:31:35.911000Z

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

IVisualizationDialog.SetInterface does not seem to work at all

2022-04-01T06:58:23.480000Z

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).

IVisualizationDialog.SetInterface does not seem to work at all

2022-04-01T06:05:12.777000Z

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.

IVisualizationDialog.SetInterface does not seem to work at all

2022-03-31T14:21:48.998000Z

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).

IVisualizationDialog.SetInterface does not seem to work at all

2022-03-31T14:13:03.705000Z

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.

IVisualizationDialog.SetInterface does not seem to work at all

2022-03-31T14:02:50.461000Z

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).

IVisualizationDialog.SetInterface does not seem to work at all

2022-03-31T06:24:25.357000Z

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

Recent posts to IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all

IVisualizationDialog.SetInterface does not seem to work at all