Poll: Keep current row visible after a sort?

[Sebastien F.]

Hi All,

We have a customers asking to change the behavior of DISPLAY ARRAY when sorting rows, concerning the current row:

For now, Genero DISPLAY ARRAY behaves like MS Explorer:
A- The current row may disappear if you sort rows.

MS Outlook and Thunderbird behave in a different way:
B- The current row remains visible after a sort.

We can support B easily but would be nice to define the expected behavior by default, and better, if nobody expects one of the behaviors, we could even avoid a new configuration parameter.

One advantage of the current behavior is: If you are on the first row (which is usually the case after a sort), if you sort rows in the descending order, you can see the rows with the biggest values (you stay at the top of the list) - the current row is actually at the bottom of the list. However, the mailers behavior seems to be more adapted in other situations.

So we have 3 choices:

1) Keep current behavior (A) and add a new FGLPROFILE entry to make current row visible after sort (B)
2) Change the default behavior to show the current row (B) and have an FGLPROFILE entry to get the MS Explorer behavior (A)
3) Change the behavior and always show the current row (B), without any configuration parameter.

I don't like much configurations parameters because this increases combinations / behaviors and makes regression tests more and more difficult to maintain.

Any comment is welcome!
Thanks a lot,
Seb

[.]

Hi Sebastien,

I think 'B' would be most customers desired bahaviour - certainly is of my users and we would welcome the change to allow the current row to remain current and visible after a sort.

Thanks

Jeff McFee

[Neil M.]

For me it should be a Style setting. As the other settings relating to the highlight bar on a table.
Sometimes method A makes more sense than method B, others times I prefer method B, as a Thunderbird user it sometimes is a pain when the resort of mails changes my view of the mails, other times it's exactly what I want.

[Sebastien F.]

For me it should be a Style setting. As the other settings relating to the highlight bar on a table.
Sometimes method A makes more sense than method B, others times I prefer method B, as a Thunderbird user it sometimes is a pain when the resort of mails changes my view of the mails, other times it's exactly what I want.

Hi Neil and thanks for the idea...

I am not sure:

Styles must be used for decoration (theoretically any end user could have it's own styles file). I don't think this is a decoration.
Anyway, I believe the clients cannot guess what position would have the current row after sort to set the offset properly.
I mean, it's technically impossible to handle this on the client side: offset to show current row must be calculated after the sort is done (= on VM side). Today we don't care at all about styles on the VM side, it's all decoration stuff handled on the client side.

Cheers,
Seb

[Neil M.]

Yes. I see that now. Styles should remain for purely decoration and this is a lower level than that.
Another alternative to fglprofile is maybe an OPTIONS statement or even an attribute on the DISPLAY ARRAY statement.
I'm not really opposed to the fglprofile entry idea, I just view it as a rather static and global setting for something that maybe people would want more control over at a TABLE level.

[Bryce S.]

Hi,

<my 2 cents worth> Just thinking of how I use windows and a behaviour I'd like... what if detect if first action in array is to re-sort (as in current row will still be first row and it hasn't been changed yet) then don't keep view of the current row as user has just come into the array and is probably re-sorting to bring something to the top?  Otherwise keep the current row visible?

Regards, Bryce Stenberg.

[Reuben B.]

How about click retains the current behaviour, and Ctrl+click does the new behaviour.  (retaining shift+click for multi-column sort one day in the future as per Outlook)

[Sebastien F.]

<my 2 cents worth> Just thinking of how I use windows and a behaviour I'd like... what if detect if first action in array is to re-sort (as in current row will still be first row and it hasn't been changed yet) then don't keep view of the current row as user has just come into the array and is probably re-sorting to bring something to the top?  Otherwise keep the current row visible?

Bryce, this is a good idea.
I will talk with others here.
Thanks
Seb

[Sebastien F.]

How about click retains the current behaviour, and Ctrl+click does the new behaviour.  (retaining shift+click for multi-column sort one day in the future as per Outlook)

Yep Reuben that's also a good point.

However, the customer asked for the exact "Outlook behavior" (simple click = sort and show current row).

So maybe we could do the other way:

- Simple click = sort and make current row visible (B) = new behavior
- Control-click = sort and keep current offset (A) = current behavior

Too all: Thanks for you valued suggestions!
Seb

[.]

My two cents:
I would not change the default current behavior.

Not everyone is reading this forum, and I imagine one can be very surprised that moving to a new version changes the behavior.

Therefore I would prefer this to be configurable (even if we use control-click), even if this makes things harder to maintain and to test.

[Rene S.]

Hello,
no panic: the current behavior will not be changed. A fglprofile entry will be added to control if the current row keeps visible while sorting.
Rene

[.]

Using fglprofile entry would make the setting almost global, thus you would be tied to that setting across applications.  Additionally, you would be tied to the same behavior throughout the same app.  I would tend to agree with Neil on how to implement the feature as an attribute of the DISPLAY ARRAY syntax.  This gives the developer the most amount of flexibility over the feature, and as an added attribute current functionality can be retained as the default behavior.

I like Bryce's ideas in regards to how the feature behaves.  The default Outlook behavior is to default to a row, and upon sort / re-sort, scrolling to the desired row is required -- this isn't always optimal behavior for sorting.  Until a row has been chosen the display will keep its current position and the array will sort, after a selection has been made the display will adjust its current position and the array will sort.

Tyson

[Sebastien F.]

Dear all,

We discussed this issue again here and finally we think it's not a very good idea to have behavior (A) and behavior (B) mixed when a new option is set...

That can confuse end users and programmers, and raises other questions like these:

1 - Should new behavior (B) be enabled when DIALOG.setCurrentRow("sr", n) is used?
2 - Once a row was selected and (B) is enabled, should the behavior get back to (A) when restarting the dialog?
3 - Once a row was selected and (B) is enabled, should the behavior get back to (A) when array is modified/re-filled by program?
4 - Should the behavior get back to (A) when selecting "Reset to defaults" in the context menu of the Table?

So we will either do 100% (A) or 100% (B) according to an option, and we would keep (A) as the default behavior.

About the option:

Instead of a DIALOG attribute (in .4gl), we thought of a .per TABLE attribute (like UNSORTABLECOLUMNS):

I believe something like "AFTERSORTMODE" attribute makes more sense as a boolean attribute.
Maybe in the future we will have a third behavior to support.

So that would give:

   TABLE t1 ( AFTERSORTMODE = DATA|DEFAULT )  -- current behavior (A)
   TABLE t1 ( AFTERSORTMODE = ROW )  -- new behavior (B)

As an alternative, the boolean option would look like:

   TABLE t1 ( SHOWROWAFTERSORT = TRUE/FALSE)   - default is false (A)

...

But is a .per attribute better than a dialog attribute?

Note that we do have already a "KEEP CURRENT ROW" dialog attribute at the .4gl level...

So maybe:

   INPUT ARRAY ... ATTRIBUTES( SHOW ROW AFTER SORT = TRUE / FALSE )

makes more sense....

Further, some may also appreciate a global setting for all dialogs of the program with:

   OPTIONS SHOW ROW AFTER SORT = TRUE / FALSE

Any comment is welcome of course.

Thank you all for your valued feedback.
Seb

[Reuben B.]

Dear all,

We discussed this issue again here and finally we think it's not a very good idea to have behavior (A) and behavior (B) mixed when a new option is set...

That can confuse end users and programmers, and raises other questions like these:

1 - Should new behavior (B) be enabled when DIALOG.setCurrentRow("sr", n) is used?
2 - Once a row was selected and (B) is enabled, should the behavior get back to (A) when restarting the dialog?
3 - Once a row was selected and (B) is enabled, should the behavior get back to (A) when array is modified/re-filled by program?
4 - Should the behavior get back to (A) when selecting "Reset to defaults" in the context menu of the Table?

So we will either do 100% (A) or 100% (B) according to an option, and we would keep (A) as the default behavior.

About the option:

Instead of a DIALOG attribute (in .4gl), we thought of a .per TABLE attribute (like UNSORTABLECOLUMNS):

I believe something like "AFTERSORTMODE" attribute makes more sense as a boolean attribute.
Maybe in the future we will have a third behavior to support.

So that would give:

   TABLE t1 ( AFTERSORTMODE = DATA|DEFAULT )  -- current behavior (A)
   TABLE t1 ( AFTERSORTMODE = ROW )  -- new behavior (B)

As an alternative, the boolean option would look like:

   TABLE t1 ( SHOWROWAFTERSORT = TRUE/FALSE)   - default is false (A)

...

But is a .per attribute better than a dialog attribute?

Note that we do have already a "KEEP CURRENT ROW" dialog attribute at the .4gl level...

So maybe:

   INPUT ARRAY ... ATTRIBUTES( SHOW ROW AFTER SORT = TRUE / FALSE )

makes more sense....

Further, some may also appreciate a global setting for all dialogs of the program with:

   OPTIONS SHOW ROW AFTER SORT = TRUE / FALSE

Any comment is welcome of course.

Thank you all for your valued feedback.
Seb

Seb,

I noticed that iTunes is effectively AFTERSORTMODE=FIRST (and it was very unannoying behaviour too) so the boolean syntax would restrict the ability to ever offer that feature in the future.

Reuben