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
Combobox Question
-
- Posts: 38
- Joined: Tue Jan 09, 2007 2:31 am
- Location: Winston-Salem, NC
Combobox Question
Charles Pratt
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
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
>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
-
- Posts: 38
- Joined: Tue Jan 09, 2007 2:31 am
- Location: Winston-Salem, NC
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
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
Charles Pratt
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Charles,
You can easily modify Class TComboBox source code to make it work the way you want:
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
...
-
- Posts: 38
- Joined: Tue Jan 09, 2007 2:31 am
- Location: Winston-Salem, NC