just don’t upgrade, it’s easy as that … that’s the only way Xojo understands.
2 Likes
The following may be an unpopular opinion, but I’ve come to love API2.
I also resisted the innovations at first. Now that I’ve switched our expert system to 100% API2 code and controls, I feel comfortable in the new environment. My code is much tidier in many areas. I’m not saying I couldn’t have done that with API1, but API2 did it automatically.
8 Likes
The choice has been made and Xojo Inc will not deviate from it. In itself, that is a good thing, I guess.
The future will tell if it is the right choice. But it doesn’t help to keep nagging about it on a daily basis, on the contrary.
Someone who keeps saying the same thing 13 times in a dozen really does become irritating and annoying (even if he is right).
everything is ok for me, I just said I’m not updating full stop
1 Like
I feel like I need more experience with API2 to fully appreciate both the improvements and the potential pitfalls. To the extent that I have used it, I liked the changes to the database classes, generally didn’t like the changes to Event names, and was a bit annoyed that some short/easy/familiar functions were renamed or name spaced creating more typing. Those two complaints are relatively minor against real improvements though (and some of the database changes are real, much needed improvements).
I did run into the problem of fragmented and incomplete documentation a few times when autocomplete didn’t have something I expected, or suggested something seemingly undocumented. It would be nice if Xojo could hire some temp help, or perhaps ask for some volunteer help, to get the documentation up to speed.
For all the complaints I see, I feel like Xojo doesn’t get enough credit for making it possible to mix API1 and API2 code in the same project. This permits a slow evolution of a code base to the new API which is critical, IMHO. My one complaint here is that I wish I could set a pragma, or check a box, which declares a function to be API1 so that autocomplete for API1 continues to work. It’s annoying to maintain API1 code with no autocomplete. And in large projects which are slowly moved to API2, there will be plenty of API1 maintenance. (There’s the Include In check box, but that didn’t affect autocomplete for me.)
One thing that does concern me is that splitting controls into Desktop/Mobile/Web, in a strongly typed language, will trickle down into code which should be the same across all platforms. It’s not a good idea to have to declare Object parameters every where and then #If TargetX your way to common behavior. The solution to this would be to implement interfaces for common functionality across all platform controls. So if you have DesktopTextField, MobileTextField, and WebTextField, you have all three implement a CoreTextField interface containing the methods supported by all three. Then we can have functions which accept CoreTextField as a parameter, and call things like CoreTextField.Text or CoreTextField.SelectAll.
+1 agree, this would be an elegant solution and doable without compiler changes, and (I think) totally backwards compatible.
Submitted as <https://xojo.com/issue/67322>
This also bugs me:
In API1:
Timer1.Mode = 1
in API2:
Timer1.RunMode = WebTimer.RunModes.Single
or
Timer1.RunMode = Timer.RunModes.Single
(which one depends on if you are using a Timer or WebTimer in a Web2 app)
An elegant solution would be for the compiler to infer the type of Enums based on context. Then, one could simply write
Timer1.RunMode = Single
which would be easier to type AND work for all Timer classes.
(Submitted as <https://xojo.com/issue/67321> )
6 Likes
I don’t see it this way at all - yes, there’s some general complaining, but we are aslo asking questions (e.g. trying to clarify what is Xojo’s plan for API2 or API3…) and we are also brainstorming solutions.
As always “Feel free to skip any thread in which you have no interest” applies here.
1 Like
Ah, but in Web there are really two sorts of timers. There’s the Web Timer which runs in the browser and then the normal timer which runs on the server. So honestly, I don’t mind this extra bit of verbosity. If I see it listed as WebTimer.RunModes.Single, then I know looking in the code that it is a web timer.
1 Like
So some of you are now posting in this thread and complaining about my complaining. I opened this thread by showing a legitimate screw up and consequence in the documentation of Xojo’s decision to Balkanize control names across platforms. I think that’s a legitimate complaint.
Second, while API2 is annoying there are some decent improvements to it. And some things do make more sense. I just don’t think that some of these changes were necessarily necessary. But that’s a matter for debate. I’m more bothered with the wholesale changing of control names between platforms while object names stay universal. Again we now have MobileButton and DesktopButton. But somehow DesktopButton works cross platform. We don’t have WindowsDesktopButton and MacDesktopButton. So we can’t we roll similarly with other frameworks?
Third, the user base complaining and the pushback Xojo received is 100% why the Xojo framework with it’s lengthy namespace notations has been deprecated. Xojo realized they made a mess there. So our voice does have an impact.
Fourth, in a MobileProject - you can’t mix API1 and API2. You are forced to upgrade everything to API2. Web is even worse between Web1 and Web2.
Fifth, Xojo’s actions have made it more difficult for a lot of us. We have to keep multiple copies of Xojo on hand and use the appropriate one. My web app needs to stay in Web1 at least until some of the mouse click issues are resolved in Web2. So I am forced to keep 2 copies of Xojo on hand and make sure I am using the right one.
Maybe those of us who are complaining are like constantly dripping water to many of you. But have you ever seen what happens over time with a constant drip of water? Change happens. That’s how rivers end up forming. Seriously, if you don’t like the thread, then don’t read it. No one is forcing you to do so. That may sound flippant but it’s true.
Last this is a community where we come to talk about a product we love and use. And sometimes we have to blow of steam and have a b-i-t-c-h session. Oh well. It helps. And sometimes we learn things.
8 Likes
True, but I would guess from Xojo’s perspective "There really are three sorts of buttons (DesktopButton, WebButton…) "
I think the point holds: the abstraction that Xojo used to do “where a Button is a Button on all platforms” was good and I miss it.
I’m not doing Mobile now, so I didn’t know this was a limiation. Good to point out, as that’s yet another confusing inconsistency.
Well, and I think the ONLY way you can mix API1 and API2 in a desktop project is if it’s a project imported from an older version of Xojo. I think if you start out with a new project, you are forced into API2 100%.
For example:
There’s some funky stuff going on with pop-up menus. Something isn’t right with them and 2021R3 broke some stuff with the legacy pop-up menu (I have another thread on this). In trying to “debug” this and see what was going on, I started a new project. I tried setting the super to Pop-up menu from DesktopPopup Menu. You can’t. It won’t let you. In fact, I was doing something and I believe it crashed Xojo. So in order to debug a problem with the legacy control, you can’t just create a new project as you’ll be forced into the new control!
This is the sort of balkanization and issues going on here. You can’t test out the new versions of Xojo on old controls with new projects! Makes debugging and doing examples to fix issues very complicated.
Yes, you have complained about that many times
As a developer whom uses a multitude of languages, yes, changes to syntax are a pain. But - its happened in every language I’ve ever used. Every single one…
C90 <> c99 <> cx9 (c language)
Don’t even get started with c++… Currently API c17 which is for the most part, like xojo, semi backward compatible but you’re still better off rewriting the code
.net - c#/and vb.net have changed drastically since the early 2000s
PHP 5.6 <> 5.8 <> 7.0 <> 7.1
Rebol… Changed like crazy, went defunct, and it’s now being branded under RedLang (language changes with every release)
JavaScript? Es6 is for the most part not backward compatible
React?
Go?
Rust?
Vb 1.0 <> vb3.0 <> vb6 <> vb.net
Every single one…
Got an entire bag of languages I’ve learned, relearned, still learning all over again.
In all honestly, Xojo has the least amount of headaches when it comes to code changes to maintain your code.
11 Likes
Why are people complaining that people are complaining? If you don’t like it just ignore it. I just read this thread and learned quite a lot about what XOJO are doing and find the replies informative, except of course from those complaining about people complaining.
10 Likes
Here is another example of how messed up things are.
MessageBox is an API2.0 construct and replaced MsgBox. Open the MessageBox documentation. You will see this:
Problem is iOSMessageBox is deprecated! It was replaced by MobileMessageBox long before MessageBox ever existed!
This is what happens when you have so many layers of stuff.
And if all of us were just sheep and didn’t point this stuff out then Xojo would never improve. If you object just put your head back down and keep eating the grass in front of you. If you don’t like the thread then don’t read it.
2 Likes
Is this a documentation problem? If so then I suggest you send documentation feedback using the link at the bottom of the page.
Already created a feedback case
1 Like
And here’s another one.
Timer. On Desktop and Web, the event name for when a timer fires is “Action.” In Mobile it is “Run.”
So what kind of sense does THAT make? Why does the Mobile Framework use a different event name??? How does that help with the portability of back end code where you are using AddHandler calls.
See, this is just the stuff that makes absolutely ZERO sense where @Geoff_Perlman and company obviously didn’t think things through.
Also, take a look at the docs. The proverbial “hobbyist” or “beginner” who is so important to Xojo (as Geoff has stated), would not think timer is usable on mobile. Mobile is not listed as a supported platform.
2 Likes
I really think that Xojo should work on a new documentation system.
2 Likes