It is perfectly understandable that different controls are used for different platforms. What I don’t understand is why the IDE and compiler couldn’t make it transparent to users. Denon and Sony may use completely different parts for the Volume controls of their stereos, but they are not labeled “Denon Volume” and “Sony Volume” - they’re labeled “Volume”. The IDE and compiler know the target platform. They should be able to select the appropriate classes without users having to manually include prefixes or suffixes in their names. The fact that previous versions of Xojo worked fine without adding this cumbersome naming requirement would seem to be evidence that it’s possible.
1 Like
You’re a Xojo programmer like the rest of us. How would you do it? Please, put some real thought into it. Tell me how you’d do it.
Not really. They are Xojo classes that use system libraries to implement the functionality.
Roll it back to however 2021r2.1 did it?
1 Like
Yeah, I figured you wouldn’t have an answer.
Well, at least he did it politely 
. In all honestly, I am refreshed Greg and Thom are being so candid with their assessment and some of the rationale of why things are the way the are. What may be a little annoyance to us may require a mountain of time to fix on their end, only to satisfy a few users that don’t like how it works.
At some point, you just have to trust them, adapt or move on…
2 Likes
I have a full-time job, and it doesn’t include designing Xojo. It’s not like I’m asking for something that’s never been done - it’s obviously possible because it worked that way before. “Go back to how it was” is actually an answer, although “I figured” you wouldn’t like it.
2 Likes
No, Xojo has never done it this way before. The class names were still different. We had PushButton, WebButton, and iOSButton. Now we have DesktopButton, WebButton, and MobileButton. We have never had multiple classes under the same name, class aliases, multiple inheritance, or any of the other things Xojo would need to make such a thing a reality. So reverting is not an answer.
In 2021r2.1, the Library shows me “Button” and “ListBox” in a desktop project. DesktopButton and DesktopListbox are nowhere to be found anywhere in the IDE or code. I don’t care what is “under the hood”, I just want an uncluttered IDE and uncluttered code.
1 Like
OK, that’s promising, thanks. So when am I ever going to see/need “DesktopXXX”? Only when casting?
You see it in the inspector’s super, when casting, or using properties/variables.
This is kind of the point we’ve been making. The amount of work required to hide the prefixes just isn’t worth it given the infrequency you actually use the class names. There’s bigger things to worry about. Is it great? No. I don’t think anybody is arguing that this is the perfect solution. But it’s definitely acceptable.
1 Like
Great, thanks for the clarification. It seems less odious now than when I first learned of it.
What strikes me is the absence of the Xojo team in this discussion. If any technical explanation in context is subject to trade secret, just say so. If not, please help your customers understanding the why and how.
1 Like
I can think of several different approaches:
Presumably, the compiler has a tokenizer. The compiler also knows what kind of project is being compiled (web, desktop…) so there could be a short list of aliases such that whenever the compiler sees “button” and the project type is desktop, the tokenizer would be given the alias string, “DesktopButton”
Interfaces: all the different variations of buttons could be implemented with a common interface called “button“ and only those features common to cross platform buttons would be included as part of the interface
The auto correct typeahead code could be made smarter so that if a person types “button“ and the project type is “desktop” then it could automatically suggest sensible answers
1 Like
I don’t understand that comment. My original post notes that the IDE already supports this feature, but only in the library pane, But it does not support it in the code editor.
The code editor does syntax checking already, and presumably that has a tokenizer as part of it. Whether that tokenizer is different than the tokenizer the compiler uses, I couldn’t say. I hope it’s not two different code paths…
I’m not getting into this, I’ll redact my comment. I apologize.
1 Like
Autocomplete is much dumber than you think. There’s more to it than that though, such as method overloading knowing what to suggest, when to include super.constructor, and so on. The IDE really is the tricky part here. Norman and I were chatting about it, and the framework would be slightly easier than I was imagining, as you could have three classes all named Button, each with different compatibility flags, and the compiler could figure out what to do. The IDE, on the other hand, would be very lost.
1 Like
For fun, I tried this:
- new Desktop project
- add Class called “Button” with superclass “DesktopButton”
- drag one of these to a Window and add some code to the Button1.Pressed event:
Voila! It seems the “Button” class works, and Typeahead works as well:
This seems like about 90% of what I’m asking for. Would it really be that hard for the IDE to do this magically in the background?
1 Like
Yes.