FiveTech Support Forums

Hi all,

there's a little glitch in the xBrowse when using the MultiSelect feature.

Example:
i select rows 3 and 5 of a xBrowse by keeping ctrl-key pressed and clicking each row with the mouse.
After i decide not to select the row 5 and click this row again ( ctrl-key is still pressed ).

Now the unwanted row 5 is actually selected but has no highlite and the row 3 has the highlite.
This is confusing for a user because it looks like row 3 is currently selected.

Regards,
Detlef

• bClrStd[/*]
  Not selected row
  
• bClrSel[/*]
  Selected row
  
• bClrSelFocus[/*]
  Focused
  
• bClrRowFocus[/*]
  Focused Row
  [/list:u]

I didn't test before, but this must help...
Maybe Antonio can solve it for you

Daniel Garcia-Gil wrote:sorry i dont understand
i see all color ok

Detlef Hoefner wrote:
If the user presses the delete button he will be surprised that row 1 will be deleted.
IMO that's a little bit irritating.

    #INCLUDE "FiveWin.ch"
    #INCLUDE "XBrowse.ch"

    function Main()

       local oDlg, aLin := {}, i, oBrw

       for i := 1 TO 6
          AAdd( aLin, {  chr( 64 + i ), "Item " + str( i ) } )
       next

       DEFINE DIALOG oDlg FROM 0, 0 TO 14, 28

       oBrw := TxBrowse():New( oDlg )
       
       oBrw:SetArray( aLin )
       oBrw:CreateFromCode()

       with object oBrw
          :nRowDividerStyle := LINESTYLE_BLACK
          :nColDividerStyle := LINESTYLE_BLACK
          :nMarqueeStyle    := MARQSTYLE_HIGHLROWMS
					:bKeyDown         := {| k | if( k == VK_DELETE,;
																			( DeleteRow( oBrw ), oBrw:refresh()), ) }


          :aCols[1]:cHeader := 'Cod'
          :aCols[2]:cHeader := 'Description'

          :bClrStd          := { || { CLR_BLACK, CLR_WHITE  } }
          :bClrSel          := { || { CLR_BLUE,  CLR_YELLOW } }
          :bClrSelFocus     := { || { CLR_HRED,  CLR_CYAN   } }
          :bClrRowFocus     := { || { CLR_WHITE, CLR_RED    } }
          :lHScroll         := .f.
          :nStretchCol      := 2
       end

       ACTIVATE DIALOG oDlg


    RETURN NIL

procedure DeleteRow( oBrw )
local nI 
local aClon := ACLONE( oBrw:aArrayData )

	for nI := 1 to len( oBrw:aSelected )
		aDel( aClon, oBrw:aSelected[ nI ]-nI+1,.f. )
	 next
	 ASize( aClon, len( aClon ) - len( oBrw:aSelected ) )
	 oBrw:aArrayData := aClon
	 oBrw:aSelected := {}
return

Daniel,

many thanks for your help.
But i already knew how to handle the :aSelected array.
My example of deleting rows was not good.

My concern is just the misleading color of a selected row while the :nArrayAt pointer is at a different row.

Here an other example where a user might be irritated.
He first selects row 1, 2 and 3.
The he deselects 2 and 1.
Row 3 stays colored and looks to be the actual row.

If he presses cursor down the browse will hilite row 2 but not row 4 as the user might think.
It is not a big problem. But it's just a none proper ui functionality.

Normally James Bott ( hi, James ) is the first address for such ui concerns.

Regards,
Detlef

This is why you must change the colors.... put a color like (255,0,0) for the focused row and (50,50,50) for the selected row....

Hi Detlef,

Samir is on the right track--you must have some way to visually tell them apart. If you look at the way Windows Explorer handles this, the active record is colored and it has a dotted black border. Normally you don't even notice this border since the color tends to hide it.

If you multi-select files by holding down the Ctrl-key and clicking then each record remains colored and only the active record has the border. If you then unselect a record, the color is removed but the border remains. Unfortunately, this is very subtle and may easily go un-noticed. Perhaps a more bold border would solve this.

Samir's idea to use two different colors still presents a problem. When the active record is both selected and highlighted, then what color should be displayed?

Another possible solution would be to add a checkbox column for use in making selections. This is a popular method used in such applications as Hotmail, GMail, etc. The current row would be the only one colored. With the checkbox, it is still easy to see when the record is also highlighted.

I think my preference would be colored selected records with a bold-border active record. I have never tried to implement this using TXBrowse so I don't know how easy or difficult this may be.

Regards,
James

Thanks for jumping in, James,

i'm still not sure about the visual appearance of a multiselect browse.
Even in Windows Explorer and other windows apps this is not handled comprehensible.

There are different methods for navigation and 'actions'.

Example:
in Windows Explorer select 3 elements with Ctrl-key pressed.
After, still with Ctrl-key pressed, deselect two elements.
Now you have one colored element and the latest deselected element surrounded with dots.

Method 1:
if you press the down arrow key, you will move from the dotted element to the next one below.

Method 2:
if you press the Del-key, you'll be asked if the colored element should be deleted.

This is no consistent behaviour.
In my opinion the record pointer should be moved backwards in select-history when deselecting elements and no 'dotting' of deselected items.
So you will never get misdirected because the last selected element is always the colored one.

Hope my view is not too wrong.
Regards,
Detlef

Detlef,

I would have to disagree with you on this point. I would find it very disconcerting if I deselected an item and then the active record jumped to somewhere else in the list (as you suggested to the last selected record). This would be really bad if the last selected item was far removed from the last deselected one (by say 500 records). What if the user wanted to deselect the one they just selected because they made a mistake and really meant to select the one below it. With your system they would be moved to the last selected record (which could be anywhere) and then they would have to navigate back to where they just were.

With the Windows Explorer method they could deselect the wrong record then select the one directly below it very easily.

Many users are familiar with Windows Explorer and if your application works completely differently, then they will be confused and upset.

I don't think it is all that confusing to have an active record that may, or may not, be a selected record.

Regards,
James