2019r2.1 is the faster IDE there has ever been since day 1, at least for Windows. So, I tolerate API2 in favor of that decent speed.
Ivan, sorry, you misinterpret my words, I can only express the information in English, I am sadly not great with many other languages except romantic based language.
My point was that 19r1 is not bug free, it is not perfect, it has many issues.
but that version is still far superior to the releases we are going to see in the next year, two years, or more.
I am saying that, however anyone regards 19r1, it will be a long time until a new and completely revised version will be as bad as the 19r1 version, it was an ironic statement, or rather opinion, that I made which I hope you might revisit and understand the meaning.
It’s news to me that serial has changed. I use it a lot, and see no difference other than some new names. I wish they would change it, to fix its erratic performance under Windows.
You rant about how horrible 2019r3.1 is, but by your own admission you haven’t even tried it and are unwilling to try it, so your criticisms carry little weight. I haven’t had to “figure out” anything under 2019r3.1, really, and it continues to be a RAD environment for me. It just works, and I use it the same way I’ve always used Xojo. I haven’t run into a “whole load of new bugs”, in fact I haven’t run into any new bugs. Maybe I don’t push the envelope as much as some. The things that annoy me in 2019r3.1 are the same things that have annoyed me since the change from RealStudio to Xojo. Some things that have annoyed me in recent years, like xojo.core.xxx are going away, yay. I only have one web app, so it remains to be seen how difficult it will be to upgrade that to Web2, but I doubt it will be catastrophic. There are some pretty smart people working on it, even if I don’t agree with all their decisions.
I think their focus is on cleaning up some past missteps like Xojo.Core, and on unifying the language so that there are fewer differences in coding for different platforms. I think these are good goals. Admittedly, things like changing Dim to Var and Append to AddRow seem capricious and misguided and I dislike them, but the fact is that Dim and Append still work, and if they ever don’t work, well, it won’t be a deal-breaker between me and Xojo.
If Xojo has shown anything, it’s that it has staying power - since 1997. I expect in a couple of years it will be better than it is now.
1 Like
oddly that was the goal for Xojo.XXXX namespacing (I’ve mentioned this before)
Hence “missteps”, lol 
Xojo.xxxx would have made it possible for Xojo to completely avoid what transpired with API 2
They could already have done what they tell us they’re going to do - a new set of controls with new properties & events
They could already have “Label” and “Xojo.label” and they’d be different controls
Yet they’d retain mostly familiar names
I cant imagine what we’re going to get now - Label and ? Pushbutton and ?
Now they need to invent all new names for every existing control to be able to have API 1 event names and API 2 ones
Oh and the Xojo.xxxx ones would not conflict with anything you or I already have defined in our projects
New global names - not so much.
Be prepared to have to rename your classes & subclasses when Xojo takes those names over as well - just the event issue in a different form
I don’t know, it just confused the heck out of me. I want one damn pushbutton and one damn timer, not two different ones where I have to figure out what the difference is. Same with all those NSS thingies, like strings whose contents you can’t even examine in the debugger. Xojo’s appeal to me is its simplicity.
As far as having to rename stuff, I don’t see (yet) why that’s so, but there’s a lot of stuff I don’t see, I guess 
Right but as things like the updates to Folderitem have show quietly updating the innards CAN have unintended side effects
Same with something like HTTPSocket if they had just changed the guts to URLConnection
So thats one reason to have 2 (probably not more)
Its allows the “old” one to be used AS IS with no changes and lets you move your code to a new one as needed or as time permitted
Thats one thing the Xojo framework did - you could mix & match and only had to worry about converting data where old code & controls needed to work with the newer code & controls
It meant there was no huge pile of deprecations to deal with all at once as well
Xojo could then add new things to that framework and NOT clobber anything you wrote or created as the names would not collide - you and I could not create the Xojo namespace or add to it
There were other reasons like being able to strip more stuff out as it was easier to actually tell if it was used or not etc
But they have not chosen to take that path 
An example is there used to be a control called StaticText
And a lot of people had placed those on layouts and named them “Label”
Then Xojo renamed the StaticText control “Label” and deprecated label
EVERY static text named “label” on every layout had to be renamed or your project would no longer compile
They run the very real risk of that occurring again because whatever new control names they use are likely to be completely global and so, like event renames, will cause a big pile of needless work
Search / Replace (with a bit of care) all “Label” with “aLabel” …
and update any code that used those names
repeat for every control in the library
fun fun fun
that ONE control way back en caused a decent amount of angst & anguish
now expand that to ever control
lets just say that given this shit storm that happened then for that one I’m glad I’m not there for these changes
I think “Label” is a bad choice for making your case as in > 95% of cases it is just a label and you do not need to ever change it (so you should just use a control array to keep clutter down in the IDE).
For items where you need to refer to the control you are of course right.
Just saying this has occurred once before and it was in an innocuous thing like StaticText. One that should be easy to deal with.
Yes you can mostly deal with replacing it with search & replace
Page Panel ? Tab Panel and anything more complicated ?
Listbox ?
Container Control ?
its gonna be messy
In my opinion, using a single word for a control name is a bad choice, anyway. Always start with “Label1” if you really want to name it along “Label” (or better: use a more precise name).
I, for one, use “Lbl” for labels (e.g. “LblPrompt”) so I’m almost certain it won’t ever conflict with something added later.
A single word, as “Label”, could have been added for several other reasons (a brand new control type, a Goto replacement/addition, some place in code for documentation, whatever); the move from StaticText to Label, as debatable as it is, isn’t the issue with guys having to rename their control names; it’s you shouldn’t use a single, correctly spelt, word alone for a control name (IMO).
I vote for changing API 2 to API TOO, with controls named LabelToo, PushbuttonToo, etc.
2 Likes
I know I would so fat finger a pushButtonToo and end up with controls named PooToo
1 Like
I’ll confess I have this bad feeling Xojo is going to say “well we released 2019r3.2 in July so …” as the days creep by wondering where/when 2020r1 is
1 Like
I think that is a given - if 2020R1 was close to release by now they would not prepare an interim release …
2 Likes
Agreed
In Xojo’s defence - they can’t win.
If they rush out 2020R1 they’ll be crucified for pushing out a buggy version and if they take their time to polish it, they get stick for being late.
Personally, I think they just need to take their time. This is painful (I’m in the same boat here as others in that I’ve renewed my Pro license this year with “nothing to show for it”) but is probably the right call.
At this present time, 2019r1.1 does not run under Rosetta 2.