FWH 16.12 : Display Seek values in Header Search Bar

[nageswaragunupudi]

Lo prometió y lo cumplió...very good, han tomado en cuenta hacer esto..? saludos, gracias...

viewtopic.php?f=3&t=30302&p=173547#p173547

You should be able to do this and more with Gets in Bar introduced in FWH 16.04

[rhlawek]

Mr. Rao,

The last sample code you posted, asking that we change it to recreate the problem, shows the problem with no modifications at all to the sample source.

Robb

[TimStone]

UPDATED: The following error message is caused by this line which you suggested, but I don't need:

oLbxcl:bClrEdits := { || { CLR_HRED, FLC_YELLOW} }

That may give you a clue as to where we might be experiencing some problems.


*****************************************************************************************************************


OK ... I have commented out much of my code, and using this, I can get a display:

Code: Select all  Expand view

  REDEFINE  XBROWSE  oLBxcl ;
      DATASOURCE oClients  ;
      AUTOCOLS ;
      ; //HEADERS "Account", "Client", "City", "Phone", "Cellular",  "Email", "Last Visti", "Total Sales";
      ; //COLUMNS "acrnum", "clicom", "clicty", "clipho", "clicel", "clieml", "clidls", "acrytd";
      ID 860 ;
      OF  oFldCSE:aDialogs[ 1 ];
        ; //ON CHANGE  ( oClientsr:load(), oFldCSE:aDialogs[ 1 ]:update() )  ;
      ; //ON DBLCLICK (  lCliScoped := oServiceUnits:ScopeUnits( oClientsr, lCliScoped ), oLbvm:refresh( ),;
        ; //    oServiceUnitsr:load( ), oFldCSE:aDialogs[2]:update( ),oFldCSE:setoption(2)   ) ;
      AUTOSORT UPDATE

    // Provide the header gradient and styles
    // oLbxcl:bClrGrad := aPubGrad
    oLbxcl:nMarqueeStyle := MARQSTYLE_HIGHLROW
    oLbxcl:nColDividerStyle := LINESTYLE_RAISED
    oLbxcl:nRowDividerStyle := LINESTYLE_RAISED
    oLbxcl:nHeadStrAligns  := AL_CENTER
    oLbxcl:nStretchCol := STRETCHCOL_LAST

    // Use for incremental search on opened database
    oLbxcl:bSeek := { |c| oClients:Seek( Upper( c )) }
  oLbxcl:lSeekBar := .t.
 
    oLbxcl:bClrEdits := { || { CLR_HRED, FLC_YELLOW} }  

 

However, if I click on an indexed column, I get the following error:

Code: Select all  Expand view

   Time from start: 0 hours 0 mins 27 secs
   Error occurred at: 12/26/16, 12:14:11
   Error description: Error BASE/1068  Argument error: array access
   Args:
     [   1] = U  
     [   2] = N   2

Stack Calls
===========
   Called from: .\source\classes\XBROWSE.PRG => TXBRWCOLUMN:SHOWSEEK( 12844 )
   Called from: .\source\classes\XBROWSE.PRG => TXBRWCOLUMN:CHECKBARGET( 12787 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:PAINTHEADER( 2237 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:PAINT( 1832 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:DISPLAY( 1693 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1697 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:HANDLEEVENT( 14217 )
   Called from: .\source\classes\WINDOW.PRG => _FWH( 3306 )
   Called from:  => DIALOGBOXINDIRECT( 0 )
   Called from: .\source\classes\DIALOG.PRG => TDIALOG:ACTIVATE( 296 )
   Called from: c:\fwh\source\function\errsysw.prg => ERRORDIALOG( 421 )
   Called from: c:\fwh\source\function\errsysw.prg => (b)ERRORSYS( 23 )
   Called from: .\source\classes\XBROWSE.PRG => TXBRWCOLUMN:SHOWSEEK( 12844 )
   Called from: .\source\classes\XBROWSE.PRG => TXBRWCOLUMN:CHECKBARGET( 12787 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:PAINTHEADER( 2237 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:PAINT( 1832 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:DISPLAY( 1693 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1697 )
   Called from: .\source\classes\XBROWSE.PRG => TXBROWSE:HANDLEEVENT( 14217 )
   Called from: .\source\classes\WINDOW.PRG => _FWH( 3306 )
   Called from:  => DIALOGBOX( 0 )
   Called from: .\source\classes\DIALOG.PRG => TDIALOG:ACTIVATE( 296 )
   Called from: c:\Projects\MLS2015\Source\mCustomer.prg => TCLIENTSERVICE:FULLEDIT( 444 )
   Called from: C:\Projects\MLS2015\Source\asw2016.prg => (b)MAIN( 352 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:CLICK( 665 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:LBUTTONUP( 901 )
   Called from: .\source\classes\CONTROL.PRG => TCONTROL:HANDLEEVENT( 1721 )
   Called from: .\source\classes\BTNBMP.PRG => TBTNBMP:HANDLEEVENT( 1843 )
   Called from: .\source\classes\WINDOW.PRG => _FWH( 3306 )
   Called from:  => WINRUN( 0 )
   Called from: .\source\classes\WINDOW.PRG => TWINDOW:ACTIVATE( 1043 )
   Called from: C:\Projects\MLS2015\Source\asw2016.prg => MAIN( 582 )

 

If I remove, AUTOCOLS and uncomment the headers and fields I want to display, then I automatically get that same error.

[TimStone]

I managed to work around it, but there is an instability here.

It involves xBrowse and the ButtonBar, specifically when using a MENUITEM with a button.

My guess is that there is a font issue ( perhaps a value not unique that is crossing between the two ).

It doesn't occur on all menuitems on button bars, but in some cases when making a menu button, it will occur. Yes, it is consistent.

Tim

[nageswaragunupudi]

Mr. Rao,

The last sample code you posted, asking that we change it to recreate the problem, shows the problem with no modifications at all to the sample source.

Robb

Can you be kind enough to indicate (a) which sample you are referring to and (b) describe the problem you are facing, (c) provide a screen shot and (d) the compiler you tried.

Thanks

[nageswaragunupudi]

However, if I click on an indexed column, I get the following error:

The reason for this error is that in the following statement

Code: Select all  Expand view

oLbxcl:bClrEdits := { || { CLR_HRED, FLC_YELLOW} }  
 

"FLC_YELLOW" is neither a declared variable or a defined constant. If you use any valid color value eg CLR_YELLOW, you would not get this error.

Note: Using compiler switches like /es2 /w1 prevents us from committing such programming mistakes.

[TimStone]

OK ... When I do a cut and paste from this forum, it embeds some extra characters into the code ( hidden ). So, I have to retype it ...

As I indicated, I worked around the problem, and just put a copy on a client's computer and got a very strange result. All bitmaps on one screen turned to a shield bmp and did not show prompts, but would show tool tips. I've never seen that shield bitmap before. It does not happen on my computer ... so I was surprised.

I will look more closely at this, but I'm still suspicious that a value used in the changes in xbrowse may conflict with a constant in the button bar.

Small samples are fine, but the reality is that, like xbrowse, our program code is extremely complex. So, when a new FWH version is released that causes a problem, and it does not exist in a previous version of FWH, then it is hard to find the exact cause, other than to know it was in a change made to the source code. This is why documentation is so important. We could actually look at the source code and read your notes to understand why you changed something. I did a comparison and can see changes related to the fonts called in xbrowse but don't know why they were made.

Tim

[ukoenig]

Mr. Rao,

I tested the first time and it works PERFECT.
I couldn't detect any problems.
The screenshot is showing from resource and using a multiple index.



best regards
Uwe

[nageswaragunupudi]

Mr Uwe

They are facing problem with MSVC 32 bits.
Despite our best efforts, we are not able to recreate the problem at our end with MSVC 32 bits also and everything is working fine. We are stuck. If someone can help us with a code that shows up the problem at our end we can surely locate the problem and fix it.

[rhlawek]

It isn't just 32 bit msvc with the problem, it exists in 64 bit as well.

I did spend some time methodically going through this tonight and figured out a couple things.

First, the order of using lSeekBar and lGetBar matters, even if the intent enable one and not the other.

i.e. the following code may look correct but it will result in the internal protected nBarHdr value set to 0, not 2 as lSeekBar := .T. implies. If the second lGetBar is set to .t. you get a GetBar not a SeekBar

WITH OBJECT oBrw
:lSeekBar := .T.
:lGetBar := .F.
END WITH

The other thing is that not only does AUTOSORT need to be enabled but, in my code at least, the search field isn't becoming visible until I click on the header of the column of an indexed field.

And, finally, one of the sample test programs provided, this link: viewtopic.php?f=3&t=33376#p196807, was still not working at all even considering the above, but I got that problem to go away by recreating the CDX index file used by customer.dbf, upon which the sample is based. After that all worked as expected.

I do have a couple questions. Is it possible to change the bmp in the seek bar from the hour glass to whatever else want? Is it possible to change the filter type it uses to instead of being a left to right match as the user types, to instead do a substring filter? I don't mean replace the left to right manner it does now, which I recognize of long established behavior. But not all searches can be done left to right.

Robb

[nageswaragunupudi]

It isn't just 32 bit msvc with the problem, it exists in 64 bit as well.

Glad it works the same way on both compilers. As we are going to see it is not a problem, but it is the intended feature.

First, the order of using lSeekBar and lGetBar matters, even if the intent enable one and not the other.

lSeekBar and lGetBar are mutually exclusive for obvious reasons. Purposefully the variables are created in such a way that only one of them can be set to .T. at a given time. This is to prevent programmers from setting both to .T. by mistake.

GetBar

Purpose of GetBar is to create GETs in header bar for those columns which the programmer decides to be used for such purpose as he my decide. XBrowse only provides a place for the GET and does not do anything else with that GET. It is totally for the programmer to decide how he wants to use the value entered in the GET.

SeekBar

Whether or not there is a seekbar, we all know that incremental seek is an inbuilt feature of XBrowse existing since many years. This works when

(a) AUTOSORT clause is used while creating XBrowse
(b) Database is sorted in the order of any one column. This is normally achieved by clicking on the header.
(c) When DBF is browsed, the DBF has to be indexed. Without index the data can not be sorted (ordered) in the order of any column. Other datasources like ADO, Array, MySql, etc do not need support of any index file.
(d) lFastEdit should be .f.

In such a case, whenever the user presses a key xbrowse seeks to the characters entered by the user.
XBrowse on its own does not display the entered value anywhere.

If the programmer desires to display the value then he needs to create a SAY like this:
@ r, c SAY oBrw:oSeek VAR oBrw:cSeek SIZE w,h PIXEL OF <someoWnd/oDlg>. When this SAY is created, XBrowse automatically displays the Seek Value in the SAY whenever user presses a valid key.

Now, instead of creating a SAY elsewhere, the programmer has another option to set oBrw:lSeekBar := .t.. In this case XBrowse automatically displays the seek value on the top of the "sorted" column in the header bar.

Now we can see that there is no problem and that the lSeekBar is working as intended.

Is it possible to change the bmp in the seek bar from the hour glass to whatever else want?

In this version it is not possible, but we plan to provide this in the next version.

Is it possible to change the filter type it uses to instead of being a left to right match as the user types, to instead do a substring filter?

Seek:

By default Seek works from left to right.
If oBrw:lSeekWild is set to .T., the record pointer moves to the first record where the value of the field contains the seek value anywhere inside. Eg. if the user enters "AU", matches with "PAUL" (Case insensitive)

Filter:

Instead of Incremental Seek(Search) it is also possible to have Incremental Filters.
For this purpose we need to set:

Code: Select all  Expand view

oBrw:lIncrFilter  := .t.
oBrw:cFilterFld := <fieldname>  // eg: oBrw:cFilterFld := "CITY"
 

(By default currently sorted sortkey is used)

If we want the seek value to be displayed in the Bar, we also need to set

Code: Select all  Expand view

oBrw:oFilterCol := oBrw:oCol( "city" )
 

By default this filters the datasource to display only values matching the expression entered by the user.

Entry "AU" results in display of all values starting with "AU" // case insensitive

If we set oBrw:lSeekWild := .t. also
Entry "AU" results in display of all values containing "AU" anywhere inside the value.

All these features are available for the last many years. What is now new is only display of the seek value in the header bar.

[TimStone]

PLEASE take the information you just shared and put it in the WIKI !

Now, to find out about behaviors in xbrowse, we must look at the WIKI ( very outdated ), then at the new features log, and then do a search through all of the xbrowse posts.

If it was placed in the WIKI article on xbrowse, it would allow more of us to fully use the features in xbrowse.

Thank you.

[rhlawek]

Rao,

That lGetBar and lSeekBar are mutually exclusive is easy to understand. That setting lSeekBar := .T., then lGetBar := .F., in this order, results in no bar being configured for display is confusing.

There is still a problem. I had mentioned that I had been using lGetBar but now it is not working correctly. Not assigning lSeekBar while assigning lGetBar := .T. will result in a seek bar that behaves as I stated in my previous post, not the expected lGetBar.

Robb

[nageswaragunupudi]

Checked again and GetBar is working properly.
Please build and run \fwh\samples\xbgetbar.prg in the samples folder.
It is working the way it should.

[joseluisysturiz]

Mr. RAO...o a quien pueda interesar...

Saludos, estoy probando esto y queria saber si hay alguna manera de seleccionar por cuales columnas se quiere hacer busqueda, algo como un aArraySeek.?

Tengo un xbrowse con un Query y hay algunas columnas por las cuales no hace falta hacer busqueda, ademas se esta presentando el caso de que si la columna contiene FECHAS, no deja escribir en el buscador ni siquiera el primer caracter y en columnas de tipo NUMERICAS tampoco dejo esribir, no se si es que la busqueda solo funciona en las columnas de tipo VARCHAR, no he leido algo sobre si esa es una limitacion.

Espero respuesta, sugerencia, aclaratoria, ideas...gracias...saludos...

--------------------- GOOGLE TRADUCTOR...
Mr. RAO ... or to whom it may concern ...: wink:

Greetings, I'm testing this and wanted to know if there is any way to select by which columns you want to search, something like anArraySeek.?

I have an xbrowse with a Query and there are some columns for which it is not necessary to make a search, besides it is presenting the case that if the column contains DATES, it does not leave to write in the searcher not even the first character and in columns of type NUMERICAS I do not know if it is that the search only works in VARCHAR type columns, I have not read anything about if that is a limitation.

I hope answer, suggestion, clarification, ideas ... thanks ... greetings ...: shock: