Button in GET problem

Patrick Mast · Post by **Patrick Mast** » Sat Aug 23, 2008 10:53 am

Hello,

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

local oWnd, cTest := "Hello world!"

to

Code: Select all | Expand

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

Post by **Antonio Linares** » Sat Aug 23, 2008 11:09 am

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 · Post by **Patrick Mast** » Sat Aug 23, 2008 11:13 am

Antonio Linares wrote: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

Post by **Antonio Linares** » Sat Aug 23, 2008 11:18 am

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 :-)

Post by **Antonio Linares** » Sat Aug 23, 2008 12:03 pm

This seems as a possible solution: WM_NCCALCSIZE

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

Post by **Antonio Linares** » Sat Aug 23, 2008 12:06 pm

Google is great :-)

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

Patrick Mast · Post by **Patrick Mast** » Sat Aug 23, 2008 12:30 pm

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

Haha, great! Just what we need! ;-)

Patrick

Rossine · Post by **Rossine** » Sat Aug 23, 2008 12:42 pm

Hello Antonio,

You can adjust this?

Thank´s

Rossine.

Patrick Mast · Post by **Patrick Mast** » Sat Aug 23, 2008 12:45 pm

Hey Rossine,

You can adjust this?

This is exact what we are talking about here.

Patrick

James Bott · Post by **James Bott** » Sat Aug 23, 2008 4:31 pm

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 · Post by **Patrick Mast** » Sat Aug 23, 2008 6:58 pm

Hello James,

James Bott wrote:>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

Post by **Antonio Linares** » Sat Aug 23, 2008 7:18 pm

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 · Post by **Armando** » Sat Aug 23, 2008 7:18 pm

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 · Post by **James Bott** » Sat Aug 23, 2008 8:58 pm

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 · Post by **Otto** » Sat Aug 23, 2008 9:43 pm

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