xBrowse Multiselect

[Detlef Hoefner]

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

[sambomb]

Change the default color of each one to achieve a good result

• bClrStd
Not selected row

• bClrSel
Selected row

• bClrSelFocus
Focused

• bClrRowFocus
Focused Row

[Detlef Hoefner]

Samir,

many thanks for your help. Your advice looks promising.

But xBrowse doesn't care about it.

here a sample:
I choosed rather weird colors to see the effects.

Code: Select all  Expand view

#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

      :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


But xBrowse still does not handle the colors user friendly.
Try to select/deselect with ctrl key pressed.

If you want to see a surprise click at an other window while this browse dialog is visible.
You'll see a color change which you can not see when staying inside your application.

regards,
Detlef

[sambomb]

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

[Daniel Garcia-Gil]

sorry i dont understand
i see all color ok

Window focus (xbrowse)


window lostfocus (xbrowse)

[Detlef Hoefner]

sorry i dont understand
i see all color ok

Daniel,

the colors may be ok.
My problem is the following:
A user gets a list with records and he wants to delete rows 1, 3 and 5.
With multiselect now problem.



But the user decided not to delete rows 3 and 1.
So with pressed CTRL key he clicks first at row 3 and than at row 1 to deselect them.
Now row 5 seems to be the only selected row.



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

Regards,
Detlef

[Daniel Garcia-Gil]

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

how do u deleted selected rows?
i do checked DATA oBrw:aSelected only saw row 5 selected...
only delete row into data ::aSelected

please check this sample...
it is you sample with few changes

compiled with xHarbour

Code: Select all  Expand view

    #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

[Detlef Hoefner]

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

[sambomb]

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....

[James Bott]

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

[Detlef Hoefner]

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

[James Bott]

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