They say its fixed but

[samRowlands]

@npalardy

But, still no reply from Geoff so its clear to me that something as simple as this to get right just isnt something that they care about doing right

What other reasons could there be?

[Torsten_B]

@npalardy

But, still no reply from Geoff so its clear to me that something as simple as this to get right just isnt something that they care about doing right

Maybe they just can’t admit to such a blatant mistake. It’s a matter of saving-my-face.

[MonkeybreadSoftware]

Thanks for posting this code.
I just put it in an issue
https://tracker.xojo.com/xojoinc/xojo/-/issues/73126

[samRowlands]

Shouldn’t you get permission from the authors of this code first?

Edit: Sigh… Dude, I am not sure you understand the issue. The problem is not which API that Xojo is reading the string from, it’s that they are parsing a string to get the OS version number and NOT using the correct API to get OS major, OS Minor and OS Bug versions.

[anic297]

@samRowlands

What other reasons could there be?

They may behave according to who’s asking…

[MonkeybreadSoftware]

Xojo seems to read major, minor and bug versions from the structure via operatingSystemVersion function.
They parse the string from operatingSystemVersionString function to get the build number.

And the build number string from the string should be removed as soon as possible to replace with the call to kern.osversion.

[npalardy]

I’d already given them this code to skip the string parsing
But … they still parse the string

[DaveS]

PERLMAN : Dana, dear, where did this code come from?
DANA    : It was send by Norman Palardy , Sir
PERLMAN : Parlardy?  Well F' that shit then

[npalardy]

@MonkeybreadSoftware

They parse the string from operatingSystemVersionString function to get the build number.

Parsing ANY of the string is what causes the code to fail under certain circumstances.
Changing languages, heck even if the () are different characters in different languages will break it.
So many ways it CAN fail.

I gave them that code BEFORE 2023r2 shipped to get the version # from the OS
But nope
Cant do that

So now we just wait to see what Apple might change that string TO and have some new crisis when/if it fails again.
Oh, and get the privilege of paying for a new “bug fix” version that maybe fixes it
(Like their first two tries to fix this issue)

And then they wonder why there are so many here that are pissed off ???

[bgrommes]

@npalardy

I gave them that code BEFORE 2023r2 shipped to get the version # from the OS
But nope
Cant do that

Not Invented Here (NIH) syndrome is hardly a new phenomenon. Although it should not really be a “thing” anymore in the realm of software development where open source is now well-accepted and people crib ideas from that and Stack Overflow and what-not on the regular. I could see some companies wanting you to sign some sort of release if they use code you specifically offer up (though many are not above just taking it without so much as a “thank you”), but ignoring best practices AND helpful input that does most of the work for you is just self-defeating.

[npalardy]

Dunno if it’s that or “Oh heck I know I can make this work the way int is now” as an ego thing ?
Either way - its wrong

@bgrommes

I could see some companies wanting you to sign some sort of release if they use code you specifically offer up

Theres an actual license on my GitHub project I originally pointed them to that contained that code
Its the standard MIT license basically saying “its free to use just put an attribution in the about box, etc”

npalardy/KitchenSink/blob/main/LICENSE

[Jeannot]

They could even make positive marketing out of it.

“Thanks to our long-standing customer and former employee, we implemented the following fix in a flash”.

Admittedly, in the true version this sounds suboptimal:

“We would like to thank Norman, who we fired and blocked in our forum for solving a bug. After all, he is still an indirect customer with us.”

[ivan]

@Torsten_B

It’s a matter of saving-my-face.

No, they can silently fix it and avoid to acknowledge the bug.

I had a problem, a silen change they made in the TextOutputStream, all the files created by the app were corrupted just by compiling the app in the new release. They just documented the change and Im sure that the plan was to gaslighting any one asking to solve that problem, “it is in the docs, you must be doing something wrong”

[Karen]

@ivan

I had a problem, a silen change they made in the TextOutputStream, all the files created by the app were corrupted just by compiling the app in the new release.

What was the change?

-Karen

[ivan]

@Karen

What was the change?

BUG on TextOutputStream when using Encodings and its workaround

[npalardy]

That issue was one reason I made my own TexttOutputStream that used a BinaryStream internally

It never touched the encoding of the data you gave it
Which was like the OLD TextOutputStream - it never touched it
I suppose they could have made the new TextOutputStream NOT do anything to the encoding IF the user NEVER set it on the stream in the constructor OR by setting the property
And converted it to the Encoding for the stream if they did

That actually would have preserved old behaviour and enabled the new one in one shot
And should have been simple enough

EDIT : well shit I thought it might be in KitchenSink
Its not
I’ll find it and add it to that project

[npalardy]

Bahahahaha !
Apparently “copy and paste this code” ISNT ACTIONABLE"

[DaveS]

just show how much “EGO” gets in the way of fixing the product…

[Torsten_B]

The Xojo boys are pathetic!

[npalardy]

any time a person stops trying to learn how to do things better its a disaster
there’s always something to learn regardless

I just do not get why they’d refused