New framework unfortunate namings

I’m trying to use the new framework as much as possible, but there are some unfortunate names picked. One in particular is the type Text (not that I can come up with an alternative right now).

Text cannot be used as a property name anymore (makes sence, but is widely used), except when it’s by importing an older project (like from RB) where you already declared a ‘Text’ property as String.

Also, the TextArea does have a Text property, but it is a String.
So you end up typing stuff like:

myControl.TextValue = TextArea1.Text.ToText

where:
myControl.TextValue is of the type Text
TextArea1.Text is of the type String => .ToText

I know this is probably (hopefully) going away once everything is converted to the new framework, but as it is now, this is confusing.

Should be easier when TextArea has a property Text of type Text into which you can put some Text :wink:

Indeed :slight_smile: But probably the TextArea control has not been rewritten with the new framework.

But as for now, We’re going to stick with String instead of the Text type anyway, as it is unbelievable slow compared to String. The speed is a disaster!

See the attached example (an experiment to translate our existing Language Engines to the new framework, so what it does will not make much sense).
The results are also slightly different (due to the ‘power’ of Text and the encodings I’ll presume and I haven’t got the time to check what exactly is different. Our existing engines handle the encodings very well with our own functions, but they are not build in this demo,)

Demo project: http://gorgeousapps.com/ABStringVsText.xojo_binary_project

Usage of the demo:

Go in your browser to the URL (+/- 65000 chars): http://en.wikipedia.org/wiki/Chinese_language

Press CTRL-a (or whatever on mac) to select everything
paste it in the Textarea

Press the buttons

I’m not sure I’d expect textfield/area’s to switch to Text type anytime soon. That would break a lot of code that has been promised to stay running for awhile. If anything we will get a new DesktopTextField like iOSTextField or Xojo.Desktop.TextField or some equivalent. The library icons is going to be a mess!

I would have preferred Unicode, or even UnicodeText, over Text.

I like that one! It clearly says what it is

+1

Over the course of the very long 2014r3 cycle, nobody mentioned the name of Text being a problem, so Text is what it’ll always be.

Well, sometimes these things take a while to figure out.

And adding an extra warning when you analyse the project that says something like: ‘Text cannot be a keyword’ (if the project has been imported from RB where it was allowed). Similar as when you try to enter it as a new one.

Text isn’t a keyword or a reserved word, it’s just a type name. From a language point of view, the following is legal (but a bad idea):

Dim text As Text = Self.Text // pretend Self has a Text property

I like the type being called Text actually. I would like to see TextField support a Content property that is the .Text in true Text form.

It can be deprecated and changed over the way StaticText was changed to Label, no? I’m not insisting on this, merely asking if it’s a potential option.

It could be, but it’s a typical cost/benefit sort of deal.

I must have a different IDE then, because mine says ‘The name connot be a keyword’ when I try to type Text into the Name field of a property :slight_smile:

All joking aside, I understand what you mean Joe. All I was suggesting was giving some warning if indeed such a ‘bad idea’ occurs. As for now, it was only by accident I noticed I had a ‘Text as String’ property. I did change it in my code to ‘TextValue as String’ because there may be a version of Xojo some day that will not allow it. And I rather handle stuff like this now when I’m doing a conversion from RB to Xojo.

The IDE message should probably say “The name cannot be a keyword or type”
Thats the IDE trying to prevent you from something like

     dim text as text = Text()

but in a property