TextField.value Deprecated?

General
1

2020r2
It seem textField.text has been recuperated, is it?

I’m unable to find the documentation about.

2

https://documentation.xojo.com/api/deprecated/textedit.html#textedit-text

1 Like
3

There is a warning on this page:
https://documentation.xojo.com/api/deprecated/textedit.html.Value

image

4

Thanks all

I was all time searching information for “Textfield.value”, and I see (as it is a subclass) it should be “TextEdit.value”

1 Like
5

I find this a very odd change - I like .value regardless of the type of control. .Text makes less sense to me personally.

6

Take the checkbox, for instance. Would “value” refer to its state or its caption? I could argue for both.

Text is explicit and I prefer so.

1 Like
7

I disagree - value should always be the field that is changeable in using that field. In computer science the “value” is the representation of the entity that can be changed.

8

Ok, my example was probably bad. Still, I’m thinking inexperienced users could think “For a TextField and a Label, “value” refers to the text shown, so it would logically be the same for a checkbox”.
Not sure there are no control which would not be confusing if “value” was common. :thinking:

9

Oh I agree for the inexperienced but then at some point programming is dependant on understanding the concepts of computing. I think Xojo should be consistent here and having different ways to extract the ‘value’ of a field seems inconsistent to me.

Not sure sure it warranted a change back to how RB used to work.

Just my opinion of course - not a huge issue either way.

10

Xojo used .Text, then .Value and we had to review all our code. Then they came back to .Text and we review our code again. In the next update they will use .String , and the following update .StringValue .
I expect a stable instruction for 2050 :smiley:

1 Like
11

And that is at the heart of the matter: a lot of changes to API2 force you to think more like a computer than a human, making the language a lot less user-friendly.

Plus it adds confusion:

TextField.value vs Val( TextField.text ) vs TextField.text.val

What if a TextField is used to enter numbers? First instinct is that it’s value is the numerical value.

The changes is API2 sounded like they hired a dogmatic IT graduate with no real life experience (but a complete disregard of the decade long history and code base that users had). It should be BASIC, not Computer Science.

1 Like
12

It’s still the value of the field -regardless of the type of data being held.

A backwards step IMO.

13

A good step backwards in mine :wink:

After all, Xojo is an object-oriented language. So you are supposed to create classes like car and employee, and talk about cars and employees in your code and not about instanceObjects of type Car and instanceObjects of type Employee even though all cars and employees are instanceObjects

So talking about the text in a TextField is the same level of abstraction that makes things easier in the first place.

1 Like