Page 1 of 1

Combobox Question

Posted: Sun Dec 23, 2007 11:11 pm
by CharlesPratt
Antonio -
Using the following code in my clipper/Fivewin apps, the "get" next to the dropdown arrow automatically shows the first element of aYr. The xHarbour/Fivewin version shows a blank get.

LOCAL oDlg, oYr, cYr, aYr := {}
aYr := GetYrs()
REDEFINE COMBOBOX oYr ;
VAR cYr ;
ITEMS aYr ;
ID 101 of oDlg

I can get it to show the first element if I do cYr := aYr[1], but I have a lot of code to change to make it the same as the clipper versions. Is this a limitation of xHarbour/Fivewin? Can I modify tcombobox to be like clipper?

Regards,
Charles

Posted: Mon Dec 24, 2007 2:24 am
by mmercado
Hi Charles:

Try this:

LOCAL oDlg, oYr, cYr, aYr := {}
aYr := GetYrs()
cYr := aYr[ 1 ]

REDEFINE COMBOBOX oYr ;
VAR cYr ;
ITEMS aYr ;
ID 101 of oDlg

Regards

Manuel Mercado

Posted: Mon Dec 24, 2007 2:47 am
by James Bott
Charles,

>Using the following code in my clipper/Fivewin apps, the "get" next to the dropdown arrow automatically shows the first element of aYr.

This is actually isn't the best behavior. How can you show if the user hasn't made a choice? Also, if I remember correctly, it SHOWS the first choice, but unless the user actually clicks on the combobox it SAVES a blank. Thus the user thinks the combobox is defaulting to the first choice (without any click), but it isn't.

>The xHarbour/Fivewin version shows a blank get.

This is better. Unless the user makes a selection, then the field remains empty. I find it is often better to allow users to leave fields blank rather than to default them to a value (or to to force the user to enter something when they don't know it). It is easier to detect an empy field (later) than to detect incorrect data that has been saved just due to design issues.

I will admit there are situations where a default value may be better such as when that value is the most common choice. This helps the user. But it has to be the most common choice by all users.

Regards,
James

Posted: Mon Dec 24, 2007 5:28 pm
by CharlesPratt
Hi James -
Thanks for your response. You're right about the best programming form, etc. However, in my case, a lot of my combos are years and/or months. in the case of years, the current year is shown in the get and the dropdown goes back in time eventually to the first year there are data. Also, where there is a combo where a month needs to be chosen, it is convenient to have "January" in the get.

I guess my issue is that I have a lot of these where there is no instruction or label on the dialog because clipper/fivewin shows the cYr in the get with the value of aYr[1] and the user can imediately see what he/she has to do when he sees two combos that show "2007" and "January" in them.

I will have to either modify the the dialogs with a label for each combo or give a value to the cYr in the code. I guess the best way is to start doing the cYr := aYr[1] with all new things and and somehow modify TCOMBOBOX to be clipper compatible and rebuild all of my existing exe's with it.

Any ideas will be helpful.

Regards,
Charles

Posted: Mon Dec 24, 2007 6:02 pm
by Antonio Linares
Charles,

You can easily modify Class TComboBox source code to make it work the way you want:

Code: Select all

METHOD Default() CLASS TComboBox
...
   if Empty( cStart ) // instead of: if cStart == nil
...

Posted: Wed Dec 26, 2007 6:59 pm
by CharlesPratt
Thanks, Antonio. This will do the job for me.

Regards,

Charles