DisplayValue Not Showing Value If LowerCase

[stanlyn]

Hi,

Using Win10p, VFP9sp2, MSSQL data source, remote view.

The problem is the combobox control's DisplayValue is empty IF the underlying data is lowercase. It does show if uppercase. There is nothing special like formatting, conversions going on, see screenshot. The lower-case values are shown at the view and ssms. Change the values to uppercase and bandaid fixes the problem. What would cause this?

From the view

From ssms

property sheet showing all non-defaulted pems.

Thanks,
Stanley

 

[Chris Miller]

Rowsource Type is 1, you're showing the list you have in Rowsource. Well, you have COM in it, but not com.

Why are you making it so complicated to yourself to have a list of TLDNs in RowSource. Use a table for that matter, and that would include all TLDs as they appear in data.

Well, or tidy up your data and decide on all TLDs being lower or upper case.

You're just stepping on your own foot.

Chriss

 

[GriffMG]

Hey Chris, go easy on Stanley (et al) B-)

Some people just have to live with the data they have, not the data they would like.
Now could it be tidied up, yes and there would be real benefits in doing that, but
that's life...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[AndrewMozley]

Is there anything we can do to discourage replies like :

Why are you making it so complicated to yourself

You're just stepping on your own foot.

I feel that they degrade this technical website and discourage people from asking questions. But there are also many polite and helpful replies from this contributor!

 

[Chris Miller]

No, you're seeing aggression where there is none. I have empathy for Stanley, I just wanted to express empathy for stepping on his own foot, it's something that happens to all of us.

Also, how could you want to stick with that data, do you really want to have COM and com in the TLD list? There is no case sensitivity of TLDs. So just do one UPDATE of the data and put it all lowercase or all uppercase. That's not hard to do, even if you would need to do it repeatedly.


Chriss

 

[vernpace]

Andrew, Griff,

Are we not being a bit too sensitive here.

 

[stanlyn]

Well, you have COM in it, but not com.

Is this case sensitive? If it is, then I do not know how I've never run into this in the past 25 years... I was expecting it to show the value, regardless of it's case, but when the user drops open the combobox, they can only pick the uppercase version.

Is this behavior specific to views? I wouldn't think so, but cannot explain why out of literally hundreds of comboboxes I defined and dealt with over the years, this is the first time I've seen this issue. Over the years has been pure vfp data.

And for large lists I create cursors in the combobox as you suggested, but since the tld list is around 10, its best handled as a value, or so I thought. At what qty would you switch from value (1) to a sql (3) generated cursor?

As for me, I really don't care about how the answer is given as I just need an answer and know the why, and thanks for that, and I'll consider it a lesson learned... I also see how our answers could suppress questions, involvement and participation.

Thanks to all...
Stanley

 

[Chris Miller]

VFP has only some case insensitive functions, like ATC().
But controlsource picks from the Rowsource by case sensitive match.

In short any comparison is case sensitive, exact an inexact matches exist, but they are both case sensitive.

You can have collations that are case insensitive, but that doesn't change how VFP is generally case sensitive. It's not so with variable names, but that regards the compiler, not string comparisons or ordering data.

I don't think it ever differed.

And no, it's not a thing differing with views vs tables.

You have an example which shows how it works, but you can see it in a demo concentrating on that very behavior. When picking a record with a lowercase TLD in the grid, the combobox will not show anything:

oForm = CreateObject("form1")
oForm.show()
Read events

DEFINE CLASS form1 AS form
	DoCreate = .T.
	Caption = "Form1"
	Name = "Form1"

	ADD OBJECT grid1 AS grid WITH ;
		Height = 200, ;
		Left = 12, ;
		RecordSource = "domains", ;
		Top = 12, ;
		Width = 180, ;
		Name = "Grid1"

	ADD OBJECT combo1 AS combobox WITH ;
		RowSourceType = 1, ;
		RowSource = "COM,ORG,NET", ;
		ControlSource = "domains.tld", ;
		Height = 24, ;
		Left = 204, ;
		Top = 12, ;
		Width = 100, ;
		Name = "Combo1"

	PROCEDURE Load
		Create Cursor domains (tld c(3))
		Insert into domains values ('COM')
		Insert into domains values ('com')
		Insert into domains values ('net')
		Insert into domains values ('NET')
		Insert into domains values ('ORG')
		Insert into domains values ('org')
		Go top
	ENDPROC

	PROCEDURE grid1.AfterRowColChange
		LPARAMETERS nColIndex
		thisform.Refresh()
	ENDPROC
ENDDEFINE

So in essence, your thread title is simply saying the truth, that's - as they always say - not a bug, it's by design.


I would extremely rarely use RowsourceType values. Perhaps in an example posted to demonstrate a simple combobox.

TLDs are data. If you're only interested in about 10 TLDs, well, that's your business, but it wouldn't matter to me, data is maintained as data and not code or even just a property of a control. So it belongs into a DBF.

You can of course set a value list you grab from data, that's a way to prevent it being hardcoded and have a central place for it to change it. That's the major thing why we have data, isn't it? So it's separate from code processing it. Even meta data typically is stored where? In DBFs.

In your case a solution would also be fetching the TLD field in upper case, SQL Server offers the UPPER function too, just like VFP.

Well, or you do build up the list from a SELECT DISTINCT TLD FROM view. That's also case sensitive. You'll always be up to date with whatever is in the data. But it would be awkward to be able to pick both "com" or "COM" from the list, then, wouldn't it?

As always, many ways to solve a problem.

Chriss

 

[stanlyn]

Chriss,

Yes, your sample form shows the exact behavior I was seeing. Don't know why I've never ran into this before. Seeing this work, I probably ran into it, but selected a value from the combo whenever it showed as blank... Don't know, just a guess, yet so rudimentary.

data is maintained as data and not code or even just a property of a control. So it belongs into a DBF.

Point taken... I do agree that if there is ever a possibility that a new group of tlds be needed, then a table is best as the code doesn't have to be messed with.

Thanks again,
Stanley