Hi Bernd,
I haven’t done much previous work with table fields, so comparing the two stacks “alternatingLinesColorTablefield.rev” and “TableField with scrolling Stripes.rev” has been very instructive. To check my understanding of the latter stack, I believe it is structured thus:
stack "Table field with scrolling stripes"
---|
---card id 1002 (script)
------|
------group "tfGroup" (script)
------comprising:
------field "TF" (script)
------group "alGroup"
---------comprising:
---------graphic "alternatingLines"
The main script the user’s mouse interacts with is in field "TF”- it is the resizeControl in this script that “synchronises” the graphic “alternatingLines” with the lines in field “TF”. The user operates the scrollbars of field “TF” to navigate the table field. The scrollBarDrag handler in field “TF” makes the vScroll of group “alGroup” match the vScroll of field “TF”. The advantage of making the graphic "alternatingLines" into the group "alGroup" is that it becomes scrollable, facilitating synchronising its scroll with that of field "TF". In the resizeControl handler, the "lock screen" command is accidentally commented out (just before “the owner of me is group “Tfgroup” comment), making resizing not as smooth as intended (indicated by the “unlock screen” later on). I was interested in the use of the “max” function to ensure the width of the graphic "alternatingLines" is never less than 0- I was not aware of this function, and it’s handy to know.
Getting the alternating stripes scrollable with the table field is definitely “easier said than done”. The problem is, you can add new lines to the table field by clicking in the lowest line of cells. This “shifts” all the previous lines upwards, and the alternating stripes should follow. However, the scroll changes, without generating a scrollBarDrag message. The “mouseDown” work-around is very elegant.(I well know the importance of locking messages when you set a scroll, if there is also a scrollBarDrag handler involved- the “lock up loop” I experienced when I neglected this was quite memorable.) From the seemingly simple “let’s make the alternating stripes scroll with the table field” a whole chain of implications follow- making graphic “alternatingLines” very large, then “packaging” everything in group “tfGroup”, then having a resizeControl handler in the script of group “tfGroup” to allow the user to resize the whole assembly correctly (necessitating the nice “selectedGroupControls” test) ... every piece must be in place for things to work correctly.
There’s another scenario to cover- if the down arrow is pressed repeatedly, it gets to the bottom of the visible table field then starts to add lines. Somehow the graphic “alternatingLines” must be made to scroll to match. rawKeyDown messages are sent to the focused control, and then on to the card. It's interesting that rawKeyDown does not go to the table field when you type in a cell, hence it is evidently not the focused object when you type, so the message goes to the card instead (as per the Rev Dictionary). We can conclude that Rev must be creating fields "on the fly", and when you click elsewhere, or hit the enter key, Rev uses the contents of the temporary field to update the text property of the table field itself, then deletes the temporary field. You can see this process in action if you place an object partially obscuring the table field, then press the arrow key repeatedly. The temporary field is created over its position in the cell (visible over the obscuring object because the new temporary field is created on top of everything else). Another thing I thought to try was putting:
Code: Select all
on mouseMove
if the shiftKey is down then
put (the name of the mouseControl)&return&(the focusedObject)
end if
pass mouseMove
end mouseMove
... in a frontScript, which lets you see the name of the cell, and its id. We can also see that the temporary field is the focused object, and thus if we are to respond to the rawKeyDown message, we have to put the rawKeyDown handler in the card script.
It’s interesting that the arrowKey message itself is not passed- this I imagine has something to do with the frontScript Rev uses to implement the table field. The rawKeyDown handler that triggers the “adapt” handler is the work-around that gets the graphic “alternatingLines” to synchronise with the table field when the “down” arrow is pressed. (One thing I wasn’t entirely sure of is why “adapt” had to be sent, rather than being incorporated in the rawKeyDown conditional).
I suspect the problem with the scroll resetting to 0 if you edit a cell, then click in another cell, is also buried in one of Rev's frontScripts:
button id 1116 of group id 1016 of card id 1002 of stack "C:/Program Files/Revolution Studio/4.0.0-gm-1/Toolset/revlibrary.rev"
... seems a likely candidate (of course, the path to the stack may be different on your computer, but I imagine the id’s are the same).
Looking at the frontScript which implements table fields offers a useful perspective. It’s not an easy thing to achieve, and in fairness to the original programmer/s it would be more reasonable to regard table fields as appreciably enhanced text fields, rather than as deficient datagrids. Table fields give a useful “add on” to a normal text field, lending it basic “spreadsheet-like” behaviour, though as we have seen, it is difficult to take it much further. The simplicity of table fields suffices in many circumstances.
This post is rather long, and while it serves to test my understanding, I hope there is also something of interest to others, who may be encouraged to inspect the relevant stacks.
Regards,
Michael
