FiveTech Support Forums

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

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

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

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

rhlawek wrote: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

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

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

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

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.

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

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

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

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?

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

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

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.

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

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.

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: