Well, Xojo has kinda stepped in it with the different naming conventions for controls across different platforms…Here’s from a bug report I just posted. <https://xojo.com/issue/67282>
Xojo has some documentation issues to solve now that you are naming things such as “DesktopControl”, “MobileControl”, etc.
The reason is that some objects like Graphics objects, cross boundaries. Look at this text from Graphics.DrawText:
But wait. RectControl has been replaced by DesktopControl. But wait. The Graphics object and Graphics.DrawText is available in the Mobile framework.
Uh-oh. You guys stepped in it. It would have made far more sense to call everything “Canvas” or “Button” instead of “DesktopCanvas” or “MobileButton.” The frameworks would then know what type of control it was. But now we don’t have that and now your documentation gets confusing. These changes are supposedly so “newbies” can code more easily. But what if a newbie who has a mobile only license is looking at the documentation, sees RectControl in the help and clicks on it only to see it’s been replaced by DesktopControl. But they don’t have a desktop license. Oh no!
I share the same sentiment regarding incomplete documentation. You can see objects have limited explanation and no examples to offer.
It happens commonly in new objects.
I think it is not a matter for experts and beginners. Both go to the documentation and see the details they do not remember or know how to do.
This blog platform is an excellent example of the questions they ask daily. You can see that there are people with experience and asking about things that perhaps we take for granted to an expert.
Agreed, Jose. But I think it could be especially confusing for a new person who has a mobile only license to follow links in documentation that appear to be only for Desktop. The problem is that all of the internal Objects like Graphics in Xojo are now completely cross platform. That’s good. But the controls are not. And that’s bad.
I suspect the big plan is 1 project for all platforms. A code that works across all platforms. The distinction between different controls can be very helpful for this.
Imagine a project that can be compiled for each platform. Only 1 project. Platform-specific controls are ignored on platforms that do not support these controls. However, the rest of the code is shared in the project.
Maybe, one day…?
But yes, the Docs are a mess now. And many Links are leading to nowhere…
A single project with 1 UI for all platforms would be a mess. I don’t think there needs to be that. But doing things like compiler directives could work. There’s no need to break UI controls into “platform” specific names as the framework should know which version to use when it comes to compilation time. We don’t have a “WindowsButton” and a “MacPopUpMenu.” They are all very different controls but the framework knows how to adjust for them.
67158 color.selectedfromdialog does not compile in web 2 projects
67132 weblistbox rowtagat not clearly documented as get/set property
66592 WebRadioGroup.SelectedIndex makes no mention of magic -1 value
66591 webradiogroup count lists docs for web listbox
66337 operator_lookup documentation is missing valid use documentation
65251 WebCookieManager Set documentation page is very sparse
64884 If you have a variant that contains an array of UNKNOWN type at compile time there is NO way to iterate the array IN the variant and put the array members into an array of variants
64871 PostgreSQLPreparedStatement is NOT subclass of PreparedSQLStatement as documented
64791 WebDatePicker initial value in Inspector
64751 WebComboBox appears to have an undocumented Hint property
63762 WebToolbarButton.ButtonStyles regarding Toggle is confusing
63480 replacelineendings documentation is inaccurate
62328 listbox cellvalue at inconsistently shown in documentation
57098 Database methods don’t say which runtime exceptions they might raise
That has been my hope, and we’re not dealing with change for its own sake. I have been gradually refactoring my code and giving Xojo the benefit of the doubt. Sure, we are told that API 1 continues to work. But I am reluctant to maintain “living” projects (as opposed to, say, a legacy one) with deprecated stuff.
For example, it seems that MobileControls have no Super.Constructor class. So how do you control initialization in custom sub-classes where you want to assign properties prior to the firing of Super.Constructor?
So far with my work with this API2 stuff in the mobile platform and it’s yuck.
Namig each control by platform is not the oposite of that??
To work across platforms you would need a LOT of conditional code. Or maybe the microsoft fiasco when they first try the “1 project”, sure, 1 project but with the same specific UI and code for each platform
Does not come as a surprise. The problems with platform specific naming had been discussed in the Testers channel when the plans arose but were ignored.
I simply fail to see the benefit of the renaming hype when the only result is more code I have to type. Xojo missed to introduce superclasses or rather interfaces that help to group similar controls on different platforms.
The hypothetic unified code project can never work if you don’t have access to a general control that could then be subclassed into desktop, mobile …
It’s exactly like you said. The current metaphor taken consequently, we should have MacDesktopButton, WindowsDesktopButton, … – all without one general button superclass in desktop projects.
And hey, the fun of updating a declare library to API 2! You can mix controls, yes. But then: Is the control you are addressing a RectControl, a DesktopUIControl or rather a Window or DesktopWindow? So the code gets blown up for literally nothing more than the sake of API 2 compatibility. In some cases controls must be rewritten from scratch just to be based on DesktopCanvas and not Canvas.
It’s the opposite of fast xplatform development. Failure by design.
Bingo. The framework has become a mess. Now you have objects that are “universal” like Pictures, Graphics, FolderItems, etc. But controls are “Balkanized” and specific. And they aren’t even consistent. For example, Subclass a MobileButton. Try to add a constructor method and call Super.Constructor. You can’t. There is no such thing. But then subclass a DesktopButton. Add a constructor method - boom - there’s the call to Super.Constructor.
I’m converting my iOSApp to MobileFramework. I’m being forced to change my events from Open to Opening even though it was an existing project.
This is becoming a mess and is frankly worse than the Xojo Framework. At least that was the beginning of platform unification. This API2 really isn’t. It’s just a new layer of mess on top of the old mess.
Until they need to use a more main stream development tool (they left the Newbie case or their needs changes or find a development job in a company or…). Then, they need to learn what every tool use (Open instead of Opening, Action instead of , etc.).
Who said its a mess ? (to capture and chain newbies to Xojo…)
Unfortunately, it’s threads like this (and others) that validate my decision to stick with API1. Call it the “fat, dumb and happy syndrome” if you wish, but I have developed some really heavy-duty business apps currently in use by large companies and NEVER found a situation during their development that could not be accommodated by the API1 language set in some manner. Granted, API2 allegedly has some “better” things … but none of which would have made my job on the apps I’ve already developed and released any easier or better. So, if I’m able to accomplish everything I need to right now with API1, why would I want to go through the machinations of changing to API2? As far as looking forward, sure, API1 won’t be around forever … but I’m 70 years old and neither will I (and yes, Emile, that’s not as old as you )
I understand that everyone’s needs are different … But it keeps coming back to “if it ain’t broke, then don’t fix it” for me.
I agree with you, Don. Unfortunately, in the case of my iOS App, I HAVE to update it to API2 so that it can eventually be released for Android when available. Plus it does make the backend easier as I’m migrating everything I use away from the Xojo framework (which was supposed to solve all our problems - yeah - right).
I am sticking with API1 for now on my main app. I’m still on Web1 for my Web app but I know it will eventually need a re-write but I am not looking forward to that.
Unfortunately, if you need to start a new project, then you will be forced into API2 or use old Xojo to start the project. That’s one way around it.
If Xojo would spend more time actually making the language better instead of trying to do it differently, think how much time they would save. Look at the coding hours put into the Xojo framework just a few years ago. Now it’s deprecated. Now it’s all API2. But what if that flops. Oh, it won’t because unlike the Xojo framework, Xojo is basically forcing you to use it.
What if they had just taken all those coding hours and just fixed bugs and made API1 better instead of re-inventing the wheel…
Just a me-too, but I’m also sticking with API-1 and Web-1 for all of my projects.
If I start a new project, I launch 2018r3.2 to load my Template app which has one of each control on a dead-code window. I then save and reopen in 21r3.1 to continue working.
Maybe if enough people push back against API2 and Balkanized_Controls_99.0 then Xojo will relent just like they did with the Xojo framework.
Xojo had a great thing going with the framework they had. All they needed to do was fix the bugs and add new features and capabilities, improve the IDE, etc. Nothing has happened in the last 7 years or so to do any of that. Instead we had an iOS framework added that is now dead. A Xojo framework that was added that’s now dead. A new Web framework that is 100% incompatible with the old web framework and is less easy to program and requires more knowledge of HTML, JavaScript and CSS (kind of the opposite of what Xojo is supposed to be). And now we have a new API with completely new commands for the same objects. Have you tried programming the graphics object in API2? Many of the old methods are gone and replaced with new ones. It’s like learning the language all over again. Now we have desktop controls. Yet another reinvention of the wheel.
It’s just a really dumb way to keep your customers. @Geoff_Perlman I hope you are reading this thread…
)