XBrowse Win7 Bar New Sample

[nageswaragunupudi]

Normal bitmaps on xbrowse win7style with background. This works well


code:

Code: Select all  Expand view  RUN

#include 'fivewin.ch'
#include 'xbrowse.ch'

function Main()

   local oDlg, oBrw, oFont

   USE CUSTOMER ALIAS CUST

   DEFINE FONT oFont NAME 'Tahoma' SIZE 0, -14

   DEFINE DIALOG oDlg SIZE 640,440 PIXEL ;
      FONT oFont TITLE 'XBrowse Gradient Rows'

   @ 10, 10 XBROWSE oBrw OF oDlg ;
      SIZE 300, 200 PIXEL ;
      COLUMNS 'First', 'Last', 'Married', 'City' ;
      ALIAS 'CUST' NOBORDER CLASS TXBrWin7() ;
      BACKGROUND "c:\fwh\bitmaps\five.bmp" FILL

   WITH OBJECT oBrw
      //
      :nMarqueeStyle    = 7 // MARQSTYLE_HIGHLWIN7  // for Windows 7 style
      //
      :Married:SetCheck()
      WITH OBJECT :First
         :AddBitmap( "c:\fwh\bitmaps\16x16\zoom2.bmp" )
         :bBmpData         := { || 1 }
      END
      WITH OBJECT :Last
         :AddBitmap( "c:\fwh\bitmaps\16x16\open.bmp" )
         :bBmpData         := { || 1 }
      END
   END

   oBrw:CreateFromCode()

   ACTIVATE DIALOG oDlg CENTERED

   oFont:End()

return nil

//----------------------------------------------------------------------------//
 

[James Bott]

Rao,

oBrw:=TxBrWin7():New(oWnSql)

While you are free to choose any method of creating XBrowse, you are not aware that by this way of creating XBrowse and the columns, you have firmly decided NOT to use any of the capabilities of xbrowse. Probably you will never know what you are missing till you change your style to the new command syntax.

Ironically, when using a subclass you have to use the above object syntax (or, define a new DEFINE to preprocess it).

Regards,
James

[nageswaragunupudi]

Rao,

Ironically, when using a subclass you have to use the above object syntax (or, define a new DEFINE to preprocess it).

Regards,
James

Mr. James

With XBrowse, using subclasses is made very easy.
The command:

Code: Select all  Expand view  RUN

@ 0,0 XBROWSE <clauses> CLASS TXBrWin7() <moreClauses>
 

actually uses TXBrWin7() instead of TXBrowse() for this browse only.

Also, if we use the command

Code: Select all  Expand view  RUN

SET XBROWSE TO TXBrWin7()

all subsequent created XBrowses use TXBrWin7() till the class is reset with another SET command. The internals of XBrowse library take care of all this work for us.

Even if the programmer prefers to create xbrowse in the oops style, FWH recommends using

Code: Select all  Expand view  RUN

oBrw := TXBrows():New( oWnd )

but NOT

Code: Select all  Expand view  RUN

oBrw := TXBrowse():New( oWnd )

because TXBrows() resolves to the currently set derived class.

Though I am myself an oops user since the birth of C++, in the case of XBrowse, I strongly advise using the command syntax, which enables bug-free and smallest application code ( both code and generated obj size ) which can be very easily maintained and modified. Also we can make the code so portable that we can change from RDD to RDMS or DataObjects and viceversa without changing even a bit of the xbrowse code.

Oops style may be used if we don't mind bloated applications, large obj file sizes, less portable code and most importantly irritating bugs and unavoidable postings in the forums. Also because by this style, we do not let the xbrowse know what we are wanting to browse and do not allow the many automated features of xbrowse.

[James Bott]

Rao,

@ 0,0 XBROWSE <clauses> CLASS TXBrWin7() <moreClauses>

I wasn't aware of this capability. Thanks for pointing it out.

I don't quite understand why command syntax would make smaller obj's. Most command syntax is just preprocessed into object syntax. Here is an example:

Code: Select all  Expand view  RUN

#xcommand DEFINE BRUSH [ <oBrush> ] ;
             [ STYLE <cStyle> ] ;
             [ COLOR <nRGBColor> ] ;
             [ <file:FILE,FILENAME,DISK> <cBmpFile> ] ;
             [ <resource:RESOURCE,NAME,RESNAME> <cBmpRes> ] ;
       => ;
          [ <oBrush> := ] TBrush():New( [ Upper(<(cStyle)>) ], <nRGBColor>,;
             <cBmpFile>, <cBmpRes> )

In the above example it makes no difference whether you use the command syntax or the object syntax as the object syntax will be used when the program is compiled.

Perhaps your comments are specific only to the xbrowse class just because of the way it was written?

Regards,
James

[James Bott]

Rao,

Here is another point re command vs object. Below is my current code to get a bitmap to display in a column (of a xbrowse). I don't think there is any way to use command line syntax to accomplish this, is there?

Code: Select all  Expand view  RUN

  // Define a bitmap in column 1
   WITH OBJECT oBrw:aCols[1]
      :bStrData := { || "" }
      :AddBmpFile(".\user16.BMP")
      :cHeader:=""
      :nEditType       := TYPE_IMAGE
      :lBMPTransparent := .t.
      :lBMPStretch     := .f.
      :bBMPData := {|| 1 }
      :nWidth:= 30
   END

Regards,
James

[Adolfo]

James, Rao...

I'm really curious why, because of the use of the command syntax of a class, you get a smaller Obj size, since the prepocessor just translates and does no optimization at all... or am I wrong ?

Maybe for simple browses, but when you really use all of its potencial you have at least...

Personalized header for each column
Personalized footer for each column
Personalized picture for each column
Personalized size for each column
Personalized bPopup for each column
Personalized color for some cells
Personalized Bitmaps for some columns

Why can I obtain reduced code or smaller obj's in this scenario... ?

Fron Chile
Adolfo

[nageswaragunupudi]

Rao,

Here is another point re command vs object. Below is my current code to get a bitmap to display in a column (of a xbrowse). I don't think there is any way to use command line syntax to accomplish this, is there?

Code: Select all  Expand view  RUN

  // Define a bitmap in column 1
   WITH OBJECT oBrw:aCols[1]
      :bStrData := { || "" }
      :AddBmpFile(".\user16.BMP")
      :cHeader:=""
      :nEditType       := TYPE_IMAGE
      :lBMPTransparent := .t.
      :lBMPStretch     := .f.
      :bBMPData := {|| 1 }
      :nWidth:= 30
   END

Regards,
James

Please see this code

Code: Select all  Expand view  RUN

  ADD TO oBrw DATA oBrw:KeyNo % 4 + 1 HEADER 'Bmp' ;
      BITMAP IN "c:\fwh\bitmaps\level1.bmp", ;
                "c:\fwh\bitmaps\level2.bmp", ;
                "c:\fwh\bitmaps\level3.bmp", ;
                "c:\fwh\bitmaps\level4.bmp"
 

You can add the clause "WIDTH 30" but I don't think it is necessary. Better XBrowse calculates the width.

At any time while creating or at runtime, if we want this column to be inserted as the first column,

Code: Select all  Expand view  RUN

ADD TO oBrw AT 1 DATA <clauses>

Now about the other assignments in your code:


:nEditType       := TYPE_IMAGE

This is NOT meant for use with bitmaps defined.

This was intended to be used for data read from database for displaying in the cells. Even this is now obsolete and instead we may use
:cDataType := "F" in case the data value read is an image file name on disk. In this case, the xbrowse will read the file and display the image as image in the cell.
if the data read from the datasource contains an image buffer, we may optionally set :cDataType := "P". Even otherwise if the data read is binary and is an image, xbrowse will automatically display it as image in the cell.
Please do not use this with bitmaps defined in the source.

      :lBMPTransparent := .t.
This is redundant.

      :lBMPStretch     := .f.
Command syntax covers many common needs and we have to write code only to handle exceptions and rare requirements. In this case we need to specify oBrw:Bmp:lBmpStretch := .t. specifically, if we need the bmp to be stretched.

[nageswaragunupudi]

Mr James

This small code demonstrates the capabilities of recognizing image buffers and memo fields automatically.

Code: Select all  Expand view  RUN

#include 'fivewin.ch'
#include 'ord.ch'
#include 'xbrowse.ch'

REQUEST DBFCDX

function Main()

   RDDSetDefault( 'DBFCDX' )

   XBROWSER 'C:\FWH\SAMPLES\WWONDERS.DBF'


return nil
 

Result:


We have never informed xbrowse that second column is an image and that the third column is a text memo.

Try resizing cell widths and heights. Both images and memo text get adjusted to the revised size.

Export to Excel and Print to printer also print images and memo properly. All this is automatic.

if you add this one line of code

Code: Select all  Expand view  RUN

  XBROWSER 'C:\FWH\SAMPLES\WWONDERS.DBF' ;
      SETUP ( oBrw:lCanPaste := .t., oBrw:Image:nEditType := EDIT_GET )
 

you can paste any image from the clipboard and the image is written into the database automatically.

Most of the times I have seen that by the old programming techniques used by our friends like oBrw:AddCol() and oBrw:bStrData, they are denying themselves the real capacities of the xbrowse. My only anxiety is that our friends are not realizing what they are missing, while I do not have any objection if they want to use xbrowse also like any other dumb browse. Golden rule with xbrowse is "less we code the better will be the results".

[mgsoft]

Hi,

Where is the latest xBrowse help documentation?

Thanks

[Adolfo]

Rao.

As I told in my last post.
Simple browses as the ones built with xBrowser are not used often in proffesional aplications, you usually try to give more control over the functions you could do with the browse.

When you browse a clients account, you want to know which document originated it, how many payments are done, and a hundred of options you could have with a single browse.

So, as I told you, with all the complex options you could give a browse, there's no possibility to use use only COMMAND creation of a xbrowse, I doubt you will use less code, and also that your obj is going to be smaller.

If I'm missing something undocumented in xbrowse, please let me know my mistake or my ignorance.
If not, I could learn something new.

From Chile
Adolfo

[James Bott]

Adolfo,

Simple browses as the ones built with xBrowser are not used often in professional applications, you usually try to give more control over the functions you could do with the browse.

I don't understand--could you give an example.

When you browse a clients account, you want to know which document originated it, how many payments are done, and a hundred of options you could have with a single browse.

So, as I told you, with all the complex options you could give a browse, there's no possibility to use use only COMMAND creation of a xbrowse,

Multiple browses are possible using command line syntax. I assume you are referring to complicated browses not being possible with command line syntax?

Regards,
James

[Silvio]

MR RAO,
Now xbrowse run ok with bmps and text Windows Seven style

Run ok also on old win xp Prof.







Only I have a problem to set the background because I use these lines of command on another class




METHOD NewGrid( nSplit ) CLASS Tmia
oApp():oGrid := TXBrWin7():New( oApp():oDlg )
oApp():oGrid:nTop := 00
oApp():oGrid:nLeft := nSplit+2
oApp():oGrid:nBottom := ::nGridBottom
oApp():oGrid:nRight := ::nGridRight

oApp():oGrid:SetBackGround("c:\work\fwh\bitmaps\five.bmp", 1 )

return nil



Ho I can set the background from here ?

[nageswaragunupudi]

Mr. Silvio

You can use

Code: Select all  Expand view  RUN

oApp():oGrid:SetBackGround("c:\work\fwh\bitmaps\five.bmp", 1 )
 

and it should work. Please let me know if you encounter any problem.

I have one advice on this usage:

Code: Select all  Expand view  RUN

oApp():oGrid := TXBrWin7():New( oApp():oDlg )
 

If FWH releases a new version with built in facility for win7 bars, you will again have to change this line to TXBrows():new(...).

Instead, retain this line as :

Code: Select all  Expand view  RUN

oApp():oGrid := TXBrows():New( oApp():oDlg )
 

Please note : You shoud use TXBrows() but not TXBrowse() all through your application. FWH recommends to use TXBrows() not TXBrowse().

and

at the beginning of your Main application module insert this line

Code: Select all  Expand view  RUN

SET XBROWSE TO TXBrWin7()

or

Code: Select all  Expand view  RUN

SetXBrowse( { || TXBrWin7() } )

Now all your browses automatically can also be used for Win7bars or normally as usual.

If and when FWH releases new xbrowse with this functionality, you just comment out the above line in the main application.

[Silvio]

yes, it make errors
look

METHOD NewGrid7( nSplit ) CLASS TMIA
oApp():oGrid := TXBrWin7():New( oApp():oDlg )
oApp():oGrid:nTop := 00
oApp():oGrid:nLeft := nSplit+2
oApp():oGrid:nBottom := ::nGridBottom
oApp():oGrid:nRight := ::nGridRight
oApp():oGrid:SetBackGround("c:\work\fwh\bitmaps\five.bmp", 1 )
return nil


error


Application
===========
Path and name: C:\WORK\prg\gut\main.Exe (32 bits)
Size: 3,273,216 bytes
Time from start: 0 hours 0 mins 16 secs
Error occurred at: 03-01-2011, 13:36:29
Error description: Error BASE/1004 Class: 'NIL' has no exported method: EVAL
Args:
[ 1] = U

Stack Calls
===========
Called from: => EVAL(0)
Called from: .\source\classes\XBROWSE.PRG => (b)TXBROWSE:TXBROWSE(383)
Called from: => TXBRWIN7:KEYCOUNT(0)
Called from: .\source\classes\XBROWSE.PRG => TXBRWIN7:REFRESH(1133)
Called from: .\source\classes\WINDOW.PRG => (b)TWINDOW:TWINDOW(569)
Called from: => TXBRWIN7:SETBRUSH(0)
Called from: .\source\classes\XBROWSE.PRG => TXBRWIN7:SETBACKGROUND(5018)
Called from: Lib\TMia.prg => TMIA:NEWGRID7(109)

[Adolfo]

James

Adolfo,

Quote:
Simple browses as the ones built with xBrowser are not used often in professional applications, you usually try to give more control over the functions you could do with the browse.


I don't understand--could you give an example.

Quote:
When you browse a clients account, you want to know which document originated it, how many payments are done, and a hundred of options you could have with a single browse.

So, as I told you, with all the complex options you could give a browse, there's no possibility to use use only COMMAND creation of a xbrowse,


Multiple browses are possible using command line syntax. I assume you are referring to complicated browses not being possible with command line syntax?

Regards,
James

1° - Im refering to the real browses used in bussiness aplications, they are not as simple as the ones created by xBrowser command... unless you give it the SETUP option with the call to fnSetup, which it can make as difficult as one created with xBrowse:New() in terms of code lines of the fnSetup

2° - Sure. Imagine you have to control clients in any store. Each client's record must show you at least this info: Personal info (1 browse, addresses ), buys (2 Browses , headers and related details), account ( 2 browses, debts and payments done ), purchase orders ( 1 browse ). For each one you wil need to format the columns, (cuantities are different from amounts ), Titles, Sizes, If there are Totals, Footers, If we are going to let the user see the actual sale ( by clicking in the xbrowse row ), or the purchase order, or the payment done. Then you will need to assign a color to the unpaid account... and so on.

There I see the difference, real and complex browses need a lot of personalization, and I don't see the benefit of using a command approach. At the end the preprocessor translates it anyways.

Moreover. Imagine a data driven xbrowse, which receives parameters from any part of the application, like :

MyBrowse( oData,aColumns,aSizes,aPictures,xRights,aSearch,bOnLClick,aM_Bitmaps)

Where the arrays could have nil values, because you can use a default value.

The only thing I'm wondering, because of my lack of knowledge or the lack of xBrowse documentation, would be better to use a Command xbrowse creation or not in this scenario.

As far as Mr. Rao saying that it will produce a reduced obj size, I don't see a benefit on it.
In fact Complex browses done with command or function must have the same code lines.

From Chile
Adolfo