tabSeq property of elements not persisting in .obj files

I have noticed that in Servoy 4.1 (on Mac 10.5, Java 6) the tabSeq property of an element is intermittently written to the .obj file. Meaning sometimes it is written and other times it is not.

Anyone else experienced this?

What is happening is that the button that moves elements from “available elements” to “selected elements” (>>) DOES NOT write the tabSeq property to the .obj files. Instead it actually removes the tabSeq property entirely. After moving an element from available to selected the up and down buttons DO write the tabSeq property to the .obj file and also the button that moves elements from selected to available (<<) DOES write a tabSeq property and corresponding value of -2.

Does this bug exist in the bug DB already? If not I will add…

Waiting for a response from Servoy.

Hi,

First of all when you edit in ‘tab sequence’ tab of form editor no changes are written to disk until you save the editor. However you can see the property tabSeq when you select an element in properties view. When it is <0 the field is not in tab sequence, when it is 0 the field is in tab sequence and the sequence is calculated through a location comparator and when it is >0, then that is its order in sequence. When you add some fields on the form the fields will have sequence 0 (default), if you move to available elements it will get sequence -2 if you move from available to selected it will get 0 again, if you move up and/or down each selected will get a number. So, I am not sure what is not working well ? Maybe you can give a small scenario that doesn’t work as expected ?

Laurian

First of all when you edit in ‘tab sequence’ tab of form editor no changes are written to disk until you save the editor

Understood.

Try this and you will see what I am talking about.

1). Open a .obj file for an element that is already placed on an existing form (open it in a text editor)
2). Take note of the tabSeq property (if it exists)
3). In Servoy Developer, open the form in form designer, then click over to the tab-order tab. If the element is already in the tab order, remove it using the << button, then hit save (you should see a tabSeq of -2 in the .obj file, in your text editor)
4). Now from within the tab order tab in Servoy Developer, move the element back into the tab order using the >> button and save the form. You will now see that instead of the tabSeq property getting an integer value as it should, it will in fact be completely missing from the .obj file.

When an element is moved from available elements to selected elements it will always get a 0 tab sequence (default). If you want it to receive a number you must move it up or down. Probably this can be improved but also is debatable what number should it receive in this situation ? You can add a case specifying how you think it should work .

When an element is moved from available elements to selected elements it will always get a 0 tab sequence (default).

No it does not, and that is the bug I am trying to report. Instead of a value of 0 being written to tabSeq: prop. the “tabSeq:” prop literal within the .obj file is entirely removed from the .obj file.

This happens because 0 is the default value, it doesn’t have to be written, it’s implicit value; I see that tab sequence is correctly set in memory. Why would it bother you that the file does not contain the tabSeq attribute ?

Now that I know the default behavior when moving an element from the available to selected panels sets the element’s tabSeq to 0, which is the default, and that the tabSeq literal will disappear from the .obj file if the value is 0, it doesn’t bother me so much. But I honestly don’t see how anyone would know that, or how it would be obvious to a developer that the default value of a tabSeq is 0. Especially when you consider that theoretically an element with a value of 0 should display in the selected panel above all other elements as opposed to below them. But if Servoy has a reason for explicitly removing the tabSeq literal and its value from the .obj file, when the default value is input, so be it, but I think that if tabSeq has a value it should be displayed in the .obj file, even if that value is 0.

jbader:
But I honestly don’t see how anyone would know that, or how it would be obvious to a developer that the default value of a tabSeq is 0.

As I said in a previous post, that’s why we added tabSeq in properties view for all elements. It is readonly property, but you don’t have to open the .obj file to see the tabSeq value but check it out there.