Button in GET problem

[Patrick Mast]

Hello,

Consider sample "GetBtn.prg".
Now, change line 5 from:

Code: Select all  Expand view

local oWnd, cTest := "Hello world!"

to

Code: Select all  Expand view

local oWnd, cTest := "Hello world!                                        "

Notice that cTest is now longer. This makes that cTest will scroll in the GET.

Notice that the carret and the scrolling text goes behind the button.

Patrick

[Antonio Linares]

Patrick,

The BUTTON is created as a child control of the GET, so you have to give the GET enough width so the text and the button don't overlay.

[Patrick Mast]

The BUTTON is created as a child control of the GET, so you have to give the GET enough width so the text and the button don't overlay.

So you can only use a button in a GET when the text its in the GET? Most of my gets are horizontal scrollable.

Like for example a customer name, it can be 10 char's or 87. So, most of the width's of the GET's are smaller than the text that can fit them and thus almost all of them are horizontal scrollable.

Patrick

[Antonio Linares]

Patrick,

The only way to get such behavior would be to find how to reduce the GET client area used to paint the text (if possible!).

Lets google for it

[Antonio Linares]

This seems as a possible solution: WM_NCCALCSIZE

http://msdn.microsoft.com/en-us/library/ms632634(VS.85).aspx

[Antonio Linares]

Google is great

http://www.gipsysoft.com/articles/BuddyButton/

[Patrick Mast]

Google is great
http://www.gipsysoft.com/articles/BuddyButton/

Haha, great! Just what we need!

Patrick

[Rossine]

Hello Antonio,



You can adjust this?

Thank´s

Rossine.

[Patrick Mast]

Hey Rossine,

You can adjust this?

This is exact what we are talking about here.

Patrick

[James Bott]

Patrick,

>Most of my gets are horizontal scrollable.

As a user I would hate that. You can't see all the data; you have to scroll each GET one at a time.

Here is what Alan Cooper has to say about horizontal scrolling, in his book "About Face The Essentials of User Interaction Design." He is talking about listboxes, but I think the same applies to edit boxes.

Listboxes can also be made to scroll horizontally. This feature allows the programmer to put extra long text into the listbox with a minimum of effort. It offers nothing to the user. Scrolling a list of text horizontally is a terrible thing, and it should never ever need to be done. ... The purpose of computers is to eliminate strain from the lives of humans.

It sounds like you are trying to put too many GETs on the same screen. Perhaps you could solve this using tabs and splitting them up into different tab panes. If you display each GET fully, and it takes two tabs, then the user can see all the data with only one click. The current design would require dozens of clicks and arrow movements to see all the data.

Regards,
James

[Patrick Mast]

Hello James,

>Most of my gets are horizontal scrollable.
As a user I would hate that. You can't see all the data; you have to scroll each GET one at a time.

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.

Anyway. If you want to use horizontal scrollable GET's or not, I still think the Caret of the GET should NOT go behind the button in the GET.



Patrick

[Antonio Linares]

Patrick,

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

James advise is very clever, but we understand that the GET has to properly work on those circunstances too.

[Armando]

Patrick:

I use the BtnGet class and that problem I have solved with the MULTI-LINE property YES

Pls, try this, I hope this can help you.

Best regards

[James Bott]

Patrick,

>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.

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



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

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

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

Regards,
James

[Otto]

Hello,
I have the same design as James.
But many times users ask why the line I that long and you can’t fill in more than a certain number of characters.
Sure you have to make the line a bit longer. There is a difference if there are many W’s or M’s or only I’s in a name.
But reading the thread I thought why don’t one make a standard length and in stead of scrolling a dynamical resize of the get?
I will try this.

Regards,
Otto