TextField Oddities

General
1

Hello again,

Here are a couple more snags that I’ve encountered in trying to update some of my code after having upgraded from RB 2008 to Xojo (Macintosh):

First, the way that TextFields behave when it comes to accepting text drops (assuming I haven’t added any relevant code myself) seems very odd. As far as I can tell, a field only automatically accepts dropped text if that field has the focus–meaning, in practice, that the drag must have originated from another window, since if you’re dragging from another field within the same window, that other field necessarily has the focus. This doesn’t seem right! Has anyone else noticed this?

Second, I just discovered this: If the text in a TextField is longer than the width of the field, so that not all of it can be displayed at once, there seems to be no way (via code) to “scroll” the text anymore. Previously I could do this via the scrollPositionX method, but although this still exists, it appears to do nothing now. Anyone know a way to accomplish this?

2

Can’t address your first issue as I have not tried that. For the 2nd issue, however, you will now need to the the TextArea control. What used to be a single control (editField) back in 2008 is now 2 separate controls (TextField and TextArea). For the longer text and automatic scrolling, you will need the TextArea.

3

[quote=170956:@Dave Jacobi]Hello again,

Here are a couple more snags that I’ve encountered in trying to update some of my code after having upgraded from RB 2008 to Xojo (Macintosh):

First, the way that TextFields behave when it comes to accepting text drops (assuming I haven’t added any relevant code myself) seems very odd. As far as I can tell, a field only automatically accepts dropped text if that field has the focus–meaning, in practice, that the drag must have originated from another window, since if you’re dragging from another field within the same window, that other field necessarily has the focus. This doesn’t seem right! Has anyone else noticed this?

Second, I just discovered this: If the text in a TextField is longer than the width of the field, so that not all of it can be displayed at once, there seems to be no way (via code) to “scroll” the text anymore. Previously I could do this via the scrollPositionX method, but although this still exists, it appears to do nothing now. Anyone know a way to accomplish this?[/quote]

Change the super of the TextField to TextArea.

4

I’m aware of TextArea, although I haven’t really looked at it yet. But TextAreas are inherently multiline, aren’t they? What I’m concerned about (with the “scrolling” issue) is when you have a single-line field but the user types something in it that’s longer than the length of the field. I’m trying to update an EditField subclass that I had in RB 2008 that I used in certain kinds of cases with single-line EditFields.

Michel, are you telling me that the text-dropping oddities that I was talking about only happen with TextFields, and that things work as expected with TextAreas? (I’m away from my regular computer and typing on my work computer right now, so I can’t actually investigate this for myself until later…)

5

A single line textField would not scroll, at least not vertically. They also don’t usually scroll horz. Typically, what happens is that the text just moves over if it is wider than the field. I believe that is typical expectation from the user.

6

These two issues disappear if you set the super of the TextField to TextArea. And contrary to what you believe, a TextArea has a setting for Multiline, as well as optional styling. Roger Clary told you from the onset.

7

Thanks, Michel Bujardet. I’ll have to play around with TextAreas next chance I get.

Roger Clary: I do understand what you are saying, but the behavior that you’re describing is what I meant by “scrolling” (i.e. I’m not talking about scrollbars here). To be clear, what I want to do is this: Under certain circumstances, when a (single-line) field that has more text than will fit gets the focus, I would like to move the text to the left so that the end of it is visible (instead of the beginning, which is the default behavior). As I mentioned, this was possible in the past via the scrollPositionX method.

Sounds like you both are telling me that my problems will go away if I use TextArea, though, so I will try that. Thanks to you both.

8

Dave, I did not say to play with a textarea. Just that a textfield can be set up as using the TextArea super, as it was the case back in 2008. You do not change anything in your code, just the super.

At the top of the inspector for your textfield, click on the pencil on the right or super, and you can switch between the two . It is a simple as that.

9

This brings up a question. Is the TextArea, when Multiline is set to NO and ScrollbarHorizontal property is set to YES, supposed to display a horizontal Scrollbar if the text exceeds the width of the TextArea? It shows a horizontal Scrollbar if Multiline is set to YES but not if Multiline is set to NO.

I’m seeing this on Windows 7 running Xojo 2015r1. Does the same thing happen on Macs? And is this the proper operation or is there a bug there?

10

Michel, all I meant by saying I would “play with” a TextArea was that I would try putting one in a window, run the project, and see how it behaves. (And just to clarify–dragging a TextField into a window and then changing its super to TextArea doesn’t do anything different than dragging a TextArea into the window to start with, does it?)

In any case…having taken a moment to try this now, I’m sorry to report that single-line TextAreas don’t seem to behave any differently from TextFields with respect to my two issues. Make them multiline, and yes–both issues do go away (well, obviously, the scrolling one only goes away if you also turn on scrollBarHorizontal–otherwise the text wraps, so the situation doesn’t arise). But unfortunately, this doesn’t help with my issues with single-line fields…

Dale–my (Mac) experience is the same; single-line TextAreas don’t display scrollbars even if you turn scrollBarHorizontal on (which is fine with me, since I don’t actually want a scrollbar)–nor does doing so make the scrollPositionX method actually work (which IS what I want…).

11

I am sorry, but before posting, as usual, I have tested for the two issues you describe with a TextField super set to TextArea. Text drop does work, as well as ScrollTo. But of course I did not set the TextField to multiline or add scrollBars. I do not see the point for a single line TF.

I do not know what you may have done, but all I am saying is that if you want the TF to behave like in RB 2008, all you have to do is to set the super to TextArea.

12

Dave, I just ran a few tests using a non-multiline textarea without a horizontal scrollbar. As I type, once the text reaches the right edge of the textarea the text scrolls left as expected. The Home and End buttons work as expected. I can move the text left or right by setting ScrollPositionX (set in code in pushbuttons) and I can set an insertion point and have the text automatically scroll to it. So, I guess I’m not clear on what you see not working.

One thing that did throw me until I read the docs what that ScrollPositionX works in pixels and not characters.

13

I don’t know what it could be that I’m doing differently from either of you, but I’m just not seeing the same results. Here is exactly what I’m doing, and what I’m seeing:

-Drag a TextField into an otherwise empty window, change its super to TextArea, and change its name to “field.” Then drag another TextField into the window and leave its super alone (this one is just here to serve as the start point for dragging text into “field”). Then drag a pushButton into the window, give it an Action event handler, and in that handler, put the line field.scrollPositionX = 30 .

At first, when I run this project, “field” continues to behave exactly the same as if I hadn’t changed the super. It’s almost as if Xojo hasn’t “noticed” the super change. So, both of my problems are present–I can’t drop dragged text into it, and pushing the pushButton does not actually make any scrolling happen no matter how much text is in the field.

Then, at some point (it seems to happen once I switch back to viewing the window’s layout after I’ve been in the code editor to add the line of code to the pushButton), Xojo does “notice” the super change Now the Inspector for “field” shows all the properties that a TextArea should have (like multiline), and its representation in the window editor is now drawn with a vertical scrollbar. In other words, the field has now basically “become” a TextArea rather than a TextField. Specifically, it’s become a multiline TextArea. Dropping text into the field now works. ScrollPosotionX still does nothing, but that makes sense; the text wraps, so there’s never any horizontal scrolling to be done.

Weirdly, in order to get the field to become single-line at this point, I have turn off not only the multiline property but also the styled property (took me a while of being really puzzled and frustrated before I figured this out!). When I do this, though, the field goes back to behaving exactly like it did at first; I can no longer drop dragged text into it, and if I type a bunch of text into the field and then press the pushButton, nothing happens.

You guys are definitely seeing different results from this, though, huh? In case it matters, my Mac is running OS X Version 10.9.5, and I’m using Xojo Version 2014 Release 3.2. Any theories as to what is going on here?

14

[quote=171640:@Dave Jacobi]I don’t know what it could be that I’m doing differently from either of you, but I’m just not seeing the same results. Here is exactly what I’m doing, and what I’m seeing:

-Drag a TextField into an otherwise empty window, change its super to TextArea, and change its name to “field.” Then drag another TextField into the window and leave its super alone (this one is just here to serve as the start point for dragging text into “field”). Then drag a pushButton into the window, give it an Action event handler, and in that handler, put the line field.scrollPositionX = 30 .

At first, when I run this project, “field” continues to behave exactly the same as if I hadn’t changed the super. It’s almost as if Xojo hasn’t “noticed” the super change. So, both of my problems are present–I can’t drop dragged text into it, and pushing the pushButton does not actually make any scrolling happen no matter how much text is in the field.

Then, at some point (it seems to happen once I switch back to viewing the window’s layout after I’ve been in the code editor to add the line of code to the pushButton), Xojo does “notice” the super change Now the Inspector for “field” shows all the properties that a TextArea should have (like multiline), and its representation in the window editor is now drawn with a vertical scrollbar. In other words, the field has now basically “become” a TextArea rather than a TextField. Specifically, it’s become a multiline TextArea. Dropping text into the field now works. ScrollPosotionX still does nothing, but that makes sense; the text wraps, so there’s never any horizontal scrolling to be done.

Weirdly, in order to get the field to become single-line at this point, I have turn off not only the multiline property but also the styled property (took me a while of being really puzzled and frustrated before I figured this out!). When I do this, though, the field goes back to behaving exactly like it did at first; I can no longer drop dragged text into it, and if I type a bunch of text into the field and then press the pushButton, nothing happens.

You guys are definitely seeing different results from this, though, huh? In case it matters, my Mac is running OS X Version 10.9.5, and I’m using Xojo Version 2014 Release 3.2. Any theories as to what is going on here?[/quote]

OK. I have looked at that again. It seems the TextField is always multiline, no matter the setting in the IDE or in code, so it wraps internally.

The solution I found is to place it on a container control and give it a very large width like 1980 or more, then place an instance of the container control onto the window. It then accepts very long lines dropping without wrapping them.