So @Geoff_Perlman here’s how API2 is much more difficult to work with in a Graphics object.
I have to have FOUR more lines of code in API2 than API1. Two lines to define temporary variable and two lines to assign the DrawingColor property of the graphics object.
How is this easier to read, or simpler for the hobbyist programmer who is so important to Xojo’s future that we need open renamed Opening, etc.
Old way:
If Condition1 Then
pic.graphics.FillColor = &cFFFF0000
pic.graphics.LineColor = &cE4CE1F00
ElseIf Condition2 Then
pic.graphics.FillColor = &c00FF0000
pic.graphics.LineColor = &c00FF0000
Else
pic.graphics.FillColor = &cFF000000
pic.graphics.LineColor = &c80000000
End If
pic.Graphics.FillOval(0,self.Height-6,6,6)
pic.Graphics.DrawOval(0,self.Height-6,6,6)
New Way:
Dim FillColor as Color
Dim LineColor as Color
If Condition1 Then
FillColor = &cFFFF0000
LineColor = &cE4CE1F00
ElseIf Condition2 Then
FillColor = &c00FF0000
LineColor = &c00FF0000
Else
FillColor = &cFF000000
LineColor = &c80000000
End If
pic.Graphics.DrawingColor = FillColor
pic.Graphics.FillOval(0,self.Height-6,6,6)
pic.Graphics.DrawingColor = linecolor
pic.Graphics.DrawOval(0,self.Height-6,6,6)
Sorry. I actually pulled that example from the iOS framework. Was thinking it was the same as the desktop API1 but probably not.
I am pretty sure there were other color options than ForeColor. Unfortunately, even in my older copies of Xojo, all the documentation is pulled from online so I can’t see what there used to be…
And what’s further curios to me, is even the MobileFramework seems fragmented. We have the Table control is now IOSMobileTable and we have IOSLayoutConstraints. I’m assuming then that tables and constraints in Android are very different animals…
This seems to be one of those painfull lessons where “change is bad.”
You might think, “what’s the harm in renaming a control (method or property)” as part of an API overhaul?
Turns out, quite a bit!
historical sample code (in blog posts, magazines, feedback cases, etc.) no longer works
documentation require multiple versions
project files are no longer backwards compatible
plugin authors have to recompile
And it’s even worse, as there are all these “unknown unknowns” we keep running into:
the IDE has to handle API1 vs API2 projects (which introduces a whole set of bugs, with weird combinations and edge cases: Virgin API2 project, API1 project that was upgraded to API2… etc.)
since API2 is not backwards compatible with API1, we are encouraged to have mixed-mode projects (with a mishmash of API1 and API2 controls). This is nice (we can upgrade slowly) but introduces a new layer or issues (what documentation does the IDE show if you have API1 and 2 controls?) Are there interopability issues between controls, etc.
I’m not sure of the right path here - “never change anything” is not a good policy either.
I am not saying never change. There’s certainly a way to evolve things so that it becomes better. Look at the way operating systems have evolved. Even with a huge change going all the way back from Mac OS 9 to Mac OS X, it was signifiant but yet the basics for the end user didn’t change. Yeah, it became a Unix based OS. But the Desktop was still called the Desktop and not ComputerDesktop. Folders were still called folders, etc.
For crying out loud, even in Windows, you can still bring up a good old command prompt and utilize DOS commands that are 40 years old!
I once read that change is not really change unless the core remains the same. An oak tree sapling grows into a big oak tree. It doesn’t change to a maple or a pine.
Xojo can evolve things and grow things but to just make changes and say, “OK. Now we are going to do it completely different” is folly. They learned nothing from the debacle and push-back of the Xojo-Framework. They only thing they learned was that in order for something to “stick” they had to make it mandatory. But even then it isn’t truly mandatory as people have posted ways to create a project with a window of dead controls in the older versions of Xojo and then bring them into the newer versions. It just makes things a mess and confusing in documentation, adds more chances of bugs, etc.
They should have fixed what was broken and gradually improved things from there. Made the necessary changes under the hood and introduced new methods and events would add new capabilities so we’d WANT to use those. But now they’ve gone backwards like removing the Super.Constructor method from Mobile controls. Why? Why? Why? Or forcing users to learn CSS in order to program in Web API 2. If I wanted to use CSS on a website, I wouldn’t use Xojo for that site!
Maybe someday Mr. Perlman will learn his lesson.
I love Xojo but I don’t love these changes nor the way they have been approaching things these last years.
Of course not, chage is good (if is an improvement) Unfortunatelly, xojo choosed a very crapy way to change things.
Change just for changing (var, messagebox )
Change way to verbose (single line msgbox vs 10 lines MessageDialog, wich looks bad since is not a real dialog )
The nonsense of allways telling “we do things half way because we dont want to break compatibility” but the break something on almost each release.
They could plan a robust framework, use real feedback, listen to the comunity who actually uses the tool for many scenarios instead of the limited vision of one or a few people not really having the user experience on different use cases, have several previews and then a complete release, Xojo 2?
But why to do it right the first time if you can add another layer of mess over the already bad design.
Whereas, on the other hand, some of us actually appreciate the conformity and intuitiveness of the new naming in API 2.
Overall I find a big block of Xojo code in API 2 much more readable and easier to understand than earlier versions of the language.
Sure, the documentation at this time is not necessarily perfect, but between the docs and this forum - when I need answers I can find them well enough.
As a result, all my projects are up-to-date with 2021r3.1, new Desktop controls and all.
this is a really hard problem to solve - the OSs keep changing dramatically (Windows 11! macOS Big Sur!) and keeping up is not easy (I know this outside of the Xojo framework)
grand plans with incomplete execution. Web2 was a major redesign (good?!) but is still barely usable - it was pushed out way too soon and buggy with no fallback. Why do the newer IDEs not support Web1, but they still support API1 for desktop?
Confusing roadmap / design: “one API to bind them all” or is it “several APIs, maybe more”
Off by one error (Indexes are now always zero based)
I suppose that Xojo needs to sold licenses, so in the near future, they will enhance the IDE by removing the read olds Project file formats to stick with 21r3.1 only.
Then, API1 will be removed since it is not updated/upgraded and now is useless.
Look at what Politics do to encourages citizens to vaccine in the last 12 months… (those who do not want)… slowly, but surely we will go to near 100%.
I don’t think so. We know Xojo does not act like this. I am sure they will leave in API1 as long as possible. They’ve always kept deprecated stuff as long as possible, in the past.
Just my two cents but why on earth are you still complaining again and again?
Xojo has gone in that direction and unfortunately there is no way back. Moaning will not help one bit. It is their product and they do what they want with it, right? Even if it costs a lot of customers (which is of course a sad thing).
So learn with it instead of complaining. That does not help yourself, others or Xojo Inc.
)
)