DCBROWSE presentation and multirow conflict

[reganc]

I was asked to add a color clause to some of the columns in a DCBROWSE today.

This browse has 5 columns. The 3rd column also used a codeblock to use the multirow capabilities.

Firstly, even before I made any color adjustments I noticed that this browse did not display correctly. The multirow column had a greater height than the other 4 columns, so the browse grid lines did not line up correctly.

Secondly, after adding a COLOR clause to only the DCBROWSE line, the multirow column did not paint correctly. I eventually took the color off that column by using a COLOR clause as follows:

COLOR {|| {NIL,NIL} } ;

I will attach an image showing what I mean.

Is there a trick to getting this to look right?

[rdonnay]

I don't understand what you mean by a multirow column.

Can I see some code?

[reganc]

I don't understand what you mean by a multirow column.

Can I see some code?

I called it multirow as that is how the documentation refers to it.

Code below:

Code: Select all

@ nROW,nCOL DCBROWSE aSEEK[AC_BROWSE] ;
         DATA aSEEK[AC_ARRAY] ;
         SIZE Rba_Col(100),Rba_Row(20) FIT;
         POINTER aSEEK[AC_POINTER] ;
         PRESENTATION aBROWPRES ;
         COLOR {|| Stop_Colour() } ;
         ITEMSELECTED {||DC_ReadGuiEvent(DCGUI_EXIT_OK,GetList)};
         FONT Rba_SayFont() ;
         NOHSCROLL ;
         SORTSCOLOR SortColour()[1] , SortColour()[2] ;
         SORTUCOLOR SortColour()[3] , SortColour()[4]

      DCBROWSECOL ;
         ELEMENT 1;
         HEADER "Account" ;
         WIDTH Rba_Col(12) ;
         SORT {|| sort_col(aSEEK[AC_ARRAY],1,.t.) } LEFTBUTTON DEFAULT ;
         PARENT aSEEK[AC_BROWSE ]

      if Sys_Lpgas()
         DCBROWSECOL ;
            ELEMENT 5 ;
            HEADER "No." ;
            WIDTH Rba_Col(8) ;
            SORT {|| sort_col(aSEEK[AC_ARRAY],5,.t.) } LEFTBUTTON ;
            PARENT aSEEK[AC_BROWSE ]
      endif

      DCBROWSECOL ;
         DATA { {|| FormatMemo(DC_GetColArray(2,aSEEK[AC_BROWSE])) } } ;
         HEADER "Address" ;
         WIDTH Rba_Col(72) ;
         SORT {|| sort_col(aSEEK[AC_ARRAY],2,.t.) } LEFTBUTTON ;
         COLOR {|| {NIL,NIL} } ;
         PARENT aSEEK[AC_BROWSE ]

      DCBROWSECOL ;
         ELEMENT 4;
         HEADER "Postcode" ;
         WIDTH Rba_Col(10) ;
         SORT {|| sort_col(aSEEK[AC_ARRAY],4,.t.) } LEFTBUTTON ;
         PARENT aSEEK[AC_BROWSE ]

      DCBROWSECOL ;
         ELEMENT 3;
         PICTURE "99" ;
         HEADER "Hits" ;
         WIDTH Rba_Col(4) ;
         ALIGN XBPALIGN_VCENTER ;
         SORT {|| sort_col(aSEEK[AC_ARRAY],3,.t.) } LEFTBUTTON ;
         PARENT aSEEK[AC_BROWSE ]

As mentioned, the 3rd column is the multirow one. The presentation array and color codeblock is only against the DCBROWSE and I've had to put a COLOR clause on that 3rd column to stop it being coloured and causing the cell to be painted in the way seen in the image.

[Tom]

DCBROWSE/multirow will not work with coloured columns and/or visual styles. This is a problem since Roger invented this stuff. Use ownerdrawing instead (samples available in the forum) - or the class Roger created last year, based on my ownerdrawing shit.

[rdonnay]

I was confused when you said a multirow column because eXpress++ has never supported such an idea.
If a column is to me multirow, then ALL columns must be the same height.

Tom is right. The old multirow stuff was ok for very limited uses.
Owner drawing will give you much more capability.

Tom invented a very good concept that was "generic" and allows many options.

I implemented a concept in eXpress++ based on his ideas.

Look at ..\samples\browse\generic.prg and ..\samples\browse\calendar.prg.

/*
This sample program uses the subclass: DC_XbpOwnerDrawBrowseGeneric().
This is a GENERIC owner drawing system for DC_XbpBrowse. Each browse
cell can draw text, icons or bitmaps anywhere within the cell by
declaring each within a multi-dimensional array.
*/

[reganc]

Tom,Roger

I was hoping the problem was trivial but it seems not. I have been putting off understanding and using OwnerDraw until it was absolutely necessary due to time constraints. But it seems that time is pretty much here.

I will have a look at the two samples you pointed to and the Express++ documentation. For the moment the current behaviour will have to stay as it is. It's only cosmetic.

Thanks for looking at it anyway.