I am new to CoDeSys and been experimenting with it for 2-3 weeks now.
I am using a table to display an array of 50 elements in target visualisation. I use SEL_ROW as the selection type with no frame around selection. I think what happens in the following is a bug with the selection manager in online mode:
Using arrow keys, I move the selection inside the table. With the down arrow, I go to the last line displayed.
At this point, pressing the down arrow again scrolls down one line of the table. That is, the newest line displayed is selected (in red due to SEL_ROW type of selection), but the cell selected by the selection manager is still the same cell as before pressing the down arrow. Pressing the down arrow will reproduce the effect up to the point that the cell selected by selection manager is on the first row displayed.
At this point, pressing the down arrow again produces an exception in the program execution. If online from the CoDeSys IDE, the software prompts for the source code of the library (visuelembase3.4) to debug the application. If looking at the Call Stack, we can see the program stuck at TransformPaintRectangle [VisuFbTransformInformation] function call.
I think what happens is that the selection manager attempts to paint a selected cell of the table that is outside of the displayed range on the table, given that it scrolled down. I am attaching a picture to help understand the critical position in the table.
If anyone has noticed or know how to fix this, I would greatly appreciate some help here!
Thanks!
Francois
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am new to CoDeSys and been experimenting with it for 2-3 weeks now.
I am using a table to display an array of 50 elements in target visualisation. I use SEL_ROW as the selection type with no frame around selection. I think what happens in the following is a bug with the selection manager in online mode:
Using arrow keys, I move the selection inside the table. With the down arrow, I go to the last line displayed.
At this point, pressing the down arrow again scrolls down one line of the table. That is, the newest line displayed is selected (in red due to SEL_ROW type of selection), but the cell selected by the selection manager is still the same cell as before pressing the down arrow. Pressing the down arrow will reproduce the effect up to the point that the cell selected by selection manager is on the first row displayed.
At this point, pressing the down arrow again produces an exception in the program execution. If online from the CoDeSys IDE, the software prompts for the source code of the library (visuelembase3.4) to debug the application. If looking at the Call Stack, we can see the program stuck at TransformPaintRectangle [VisuFbTransformInformation] function call.
I think what happens is that the selection manager attempts to paint a selected cell of the table that is outside of the displayed range on the table, given that it scrolled down. I am attaching a picture to help understand the critical position in the table.
If anyone has noticed or know how to fix this, I would greatly appreciate some help here!
Thanks!
Francois
Actual image...
please use latest version this helps a little but not everything is correct with tables and trends.
Thank you,
I had confirmation from support that this is a bug that is targeted to be corrected with the SP2 release somewhere by the end of 2010.