Button in GET problem

[xProgrammer]

Hi all

I agree with James that horizontally scrolling GETs are ugly and confusing for the end user. They waste time during data input. Its interesting that if one is using xBase data files the problem shouldn't normally exist given that the data base itself will have finite field sizes. But of course SQL Server type data bases have varchar fields and if you are using say XML as a backend no limits apply. Even so I think there are reasonable limits one can apply. In the case of an address you can provide a perfectly serviceable address even if in some rare instances a little bit of abbreviation or shortening may be required. Also to a certain extent you are only shifting the issue here. I have never yet seen a horizontally scrolling window faced envelope. From a system design point of view I believe that you are better off facing an issue such as this at the point of data entry so that the user knows what she or he enters is what will be used / visible and not cut off by either being hidden by an envelope window, only partly shown in a report etc. Like James I offer an extra line for an address.

Having said all that I understand that everyone is entitled to try to produce code that works the way that they think is the best and heaven help us if everyone agreed with me! But I would recommend strongly against horizontally scrolling GETs.

REgards
Doug
(xProgrammer)

[Patrick Mast]

We are already working on it to provide a fix asap using those urls info

Thank you Antonio.

Patrick

[Patrick Mast]

Hey James,

>I disagree. Lets say you have an address line on your form. You never know how many characters you need for a address line. So, you make the GET that holds the address line extra wide? Hmm.. design-wise? Not a good decision I think.

Well, it doesn't really matter what you or I think (as programmers), it matters what the users think. Your answer reiterates what Alan Cooper said, that it is easier for the programmer but not for the user. You seem to only be looking at it from an ease of programming view.

Well, I have been developing End Users applications for 25 years now. I only develop what my users ask. And I'm Nr1 in my country on accounting software. So..

I have never had a problem making an address line wide enough. Also, I always add an extra line too.

Hey, nice looking screen! Ok, now lets say my email address is "michele.van.den.aakhoornlaan@sweertsmichele-bvba.com"
How is this going to fit in your email GET?

Have you ever seen another program with a screenful of scrolling GETs?

I see a horizontal scrolling GET as a extra users freindly way of letting the user type in LONGER text than I as a programmer forsee. Its a PLUS!

As a user I might tolerate one or two scrolling GETs but not a whole screenful of them.

As a user I would call my developer and ask him WHY it is that my email does not fit in to the FIXED lenght GET the developer provided me. Why would we LIMIT the user in typing ONLY the digits we let them to?

Why don't you ask some of your users what they think?

Believe me James, I do!

No hard feelings. Lets just conclude that we have a different opinion on this subject. For sure, I do respect your view.

BTW, this is my customer form:


Patrick[/img]

[James Bott]

Patrick,

OK, after seeing your screen perhaps I misunderstood what you were describing. I thought that you were saying that all your GETs were too short for the typical entry so one could not see the entire entry for any of the GETs. This would be very frustrating.

Now, it looks like yours are only used on the very rare occasion. Is that true?

I am not sure how you store this data. Do you just have very long fields for everything? And as Doug said, how do you deal with this on reports, etc? Do you truncate the long data if it won't fit?

I am aware of your background and your product and I have great respect for you too, Patrick. And, I do think that bringing up controversial topics like this can benefit everyone. I always hope people challenge my views too, so I (and others) may benefit.

Best Regards,
James

[Otto]

I tried something like that but somewhere is a mistake I can’t find out:

@ 2, 2 GET oGet VAR cTest SIZE nWidth, 22 ON CHANGE (nLaenge := oGet:GetWidth(ALLTRIM(cTest)),;
Iif(nLaenge > nWidth,( oGet:nWidth( nLaenge + 5 ),oGet:refresh() ,))

Regards,
Otto