UTF-8 Character output

It certainly seem that technical discussion were at a much higher level in the past and have been diminishing since about the change from Real* to Xojo. It was really valuable to me way back when.

If what Tim posted on TOF about Geof removing much of the documentation on inheritance because it’s an advanced topic most do not need to know is correct, there is no hope of things changing for the better.

-Karen

When you looked at the NEW documentation site for something like Label - specifically DesktopLabel

https://documentation.xojo.com/api/user_interface/desktop/desktoplabel.html

the “inheritance” hierarchy used to exist at the top of the page

now its buried way at the bottom - WAYYYYYY at the bottom
And since all pages are now one giant long list of everything when I say “way at the bottom” I mean a LONG scroll down
Open the link above and scroll and scroll and scroll

and easy to overlook - even if you KNOW what youre looking for

the breadcrumbs at the top of the page are “category” crumbs that have nothing to do with inheritance etc
Just what section of the guide things exist in

Why I submitted
https://tracker.xojo.com/xojoinc/xojo/-/issues/72614

This is a bit of a tangent, but…

I don’t recall if it was Web 1.0 Labels or Buttons, but one of them you could not style the text due to how Xojo built the html. So annoying. I’m not sure it was ever fixed.

When I noticed the documentation was missing inheritance information, I reached out to talk about it. He clearly didn’t understand inheritance himself, and proceeded to tell me it was an “advanced topic” and that users wouldn’t need to know about it.

Apparently he had a similar discussion with Julian.

I don’t use the new docs… That long page and it’s organization make it really hard to really grasp and understand things!

-Karen

2 Likes

Are these conversions built into the language?

I have a trick for you: the :arrow_lower_right: key (or fn+⇟ on a laptop) :wink:

But of course, the documentation is not of ease.

P.S.: the :arrow_lower_right: arrow looks better when composing than when actually posted, but I won’t change it.

No wonder Xojo is crapping the bed.

If you only care about onboarding new users and don’t give a crap about when folks become advanced, you end up with the Pros leaving. Good job, Xojo!

1 Like

https://docs.xojo.com/Text
see Converting Text to and From Bytes

Oh sure NOW I know where it is
When I first was looking for it I never dreamt that it would be put at the END of the pages
So I couldnt find it
And then the styling makes it less than obvious

The layout is so bad its harder to read than ever
There’s almost NO distinction between header and body text in many cases
The old docs will serve me well for a long time - even for NEW stuff :stuck_out_tongue:

1 Like

just re-read this post

it explains a TON

2 Likes

Lol THAT’s an advanced topic that it’s not fundamental to understand? You’re right, we’re screwed. By that logic they should remove inheritance from the product as well.

If OTOH they’ve decided that inheritance is a “given” that is prerequisite knowledge to using it, which is obtainable elsewhere, and so they aren’t going to cover it in the docs, that’s at least a coherent, if misguided position (particularly misguided if they are focusing now on non-professional devs, who would greatly benefit from being shown how inheritance works in Xojo so they don’t have to map it from some other language example somewhere out in the ether).

By what I am reading in this thread, the deprecation of Text, instead of fixing its performance issues, could be attributed to the fact that Xojo does not have a compiler specialist.

I think it was more that they “hid” the location of the inheritance info on each page as I noted

But they’re having a webinar on “HOW TO” so we can all learn this important stuff

But in an OOP language and tool HOW can the very basis of OOP be “advanced” ?

Lets just say that users bitched abut having two types (that did different things well)
And the new Xojo framework had a CLEAR split between bags of bytes (using memory blocks) and TEXT. String is both - with pros & cons in each

Which upset some who tried to port their entire lives to the new set up and ran into speed issues.
IF you used BYTES to mean “textual data” and expected to manipulate UTF encoded text as “runs of bytes” then yes TEXT was NOT going to save you a thing
DONT MOVE to it
There was NO requirement to do so
The entire Xojo framework was OPTIONAL with means to convert between things IF needed

This was another victim of “OMG there’s something new I MUST move to using it immediately” where there was NO compelling reason to make such a change

Now its been deprecated an the things TEXT did well will eventually be dropped in favour of String and its set of incorrect behaviours

1 Like

Pffff, Xojo has no clear product strategy, apart from trying to be attractive to the ‘new customer’.

THIS…

Xojo is carrying around a bucket of water, full of holes, racing to try to add more water.

There’s a hoooole in the bucket oh Genius oh Genius…

While I didn’t express my thoughts about it, back then, I fairly recall iOS didn’t used strings, and sharing classes between desktop and iOS was a nightmare just by needing “characters” in the class (unless you’d use an array of integers to represent code points, but what a workaround!).

At those times, I really wanted both types to merge or become compatible with each other.
I’m not saying the text type had to be removed, but I understand why some users disliked and didn’t understand the need for both, because, again back then, having them both broke items sharing while adding “little enhancement” (vs a break)).

Yes sharing code between iOS and any other target was definitely challenging
The Xojo framework, required on iOS, could be used elsewhere
It just never got expanded - in part because of the push back by a very vocal users who hated on it which was listened to

code points ARE integers - when you look up anything in the UTF-= 8 charts you see the “code point” (character number whatever you want to call it) which is just an indexed number
The BYTES that represent that code point are entirely different in most cases(except in the case of the original <128 codes which are ASCII)

If you consider “working right” a little enhancement well
Strings have lots of odd behaviours we have all just dealt with over time
But they do lots of things wrong - and they LET you do wrong things (adding a nil encoded string to one that has an encoding and NOT giving you any indication that this is rather nuts to do for TEXTUAL data)

Text fixed those weird things and made it obvious when you tried to do silly things
The goal was to help YOU write better more correct code from the outset
Something string doesn’t to

Not sure it can subsume TEXT under the hood to be text when there is an encoding and string, with all its ugliness, when there isnt one since TEXT represent TEXT completely differently than STRING

Either way its moot
I doubt anyone there will invest the kind of time & effort it would take to do that change

they do => LOW CODE?, ZERO CODE?, NO CODE?, BAD CODE? … why mentioning inheritance? :slight_smile:

Xojo 2031R4: the only product compiling no code for all platforms.

Yes, I know. But when you have an array of integers, they can represent other things than code points, hence my statement.

Agreed.