...
Case Button
Select case CurrentProyectType
Case Desktop
'Autocomplete for DesktopButton
Case Mobile
'Autocomplete for MobileButton
Case Web
'Autocomplete for WebButton
End Select
...
Looks very hard
1 Like
I’m not going to participate in a bad faith discussion about this.
3 Likes
I just did a search in a mid-size web 2 app that we currently have in production. Not once do we have any code that references WebButton. We typically drag a “Button” on to a page and in the Button.Pressed event call a method. No where do we ever need to refer to a WebButton. If you are dynamically adding buttons to a page, you would need to use the WebButton class name, but otherwise, why would a single generic class called Button be incredibly better than DesktopButton, WebButton and MobileButton?
I think it became clear halfway through this discussion that much of the panic and dissent has been based on ‘I don’t want to have to keep typing desktopbutton instead of button’
where it has become apparent that actually, we don’t have to, except in those rare circumstances where we might cycle through a window’s controls and perform actions based upon whether a control ISA Desktopbutton
I’m certainly guilty of this misapprehension, so apologies to those who need an apology, and I would perhaps have known if I had decided to adopt API2
(I haven’t, and I don’t want to, particularly.)
2 Likes
Fair point. I don’t have that pattern much either.
Where it does bother me, however, is WebTimer.
In API1:
timer1.mode = timer.modeSingle
In API2
timer1.mode = WebTimer.RunModes.Single
A case where I would argue that WebTimer and Timer should either share the same interface, or inherit from the same subclass, so that this extra detail wouldn’t be necessary.
4 Likes
Yes, there are a lot of class constant enumerations involved in everyday usage of Xojo, and that’s where mandatory prefixing will likely be most annoying.
But aren’t those class constants almost always, er, constant across platforms? Do the RunModes of WebTimer differ from those of DesktopTimer? Do the column alignments of WebListBoxes differ from those of DesktopListBoxes?
You still don’t need to reference WebTimer here.
timer1.mode = timer1.RunModes.Single
1 Like
It could also be said for a lot of things. Like rectControl and desktopControl share a lot of properties (width, height, etc) yet lack a common class, so specific code and functions must be created for rectControl and desktopControl.
public function fixWidth( extends r as rectControl ) {
r.width = <fixedWidth/>
}
public function fixWidth( extends r as desktopControl ) {
r.width = <fixedWidth/>
}
Which could be expanded across web and iOS and I assume Android may have it’s own prefix (if iOS does).
Which raises the question, Should DesktopControl have been a subclass of RectControl, at least until RectControl is removed (years in the future)? Unfortunately, we are not privvy to the underlying reasons for the current choice of implementation. I trust that Xojo made the best choice among a plethora of unfortunate options.
In these situations, the best decision is to scrap everything and do a complete rewrite. Which is also the worst decision.
Maybe. But it future proofs the language from the possibility that Apple or Chrome may implement something else.
i think at other languages you would have a namespace and could shorten the spelling
Windows.UI.Button
MacOS.UI.Button
Web.UI.Button
IOS.UI.Button
Android.UI.Button
Cross.UI.Button 
using Windows.UI
RuntimeButton1 = New Button
other IDEs have a extra project type for each target.
At first Xojo used namespaces, but luckily they got rid of it. 
2 Likes
it have pro and cons.
1 Like
Are-you using them in the same project ?
or
Can you use them in the same project ?
Similar to the Documentation, if the Project is Desktop, I only want to read the Desktop part of the Documentation: displaying Mobile or Web entries are useless.
So, with a Desktop project, only Desktop Controls can be used.
Am I Right or Wrong ?
2 Likes
This endless whining is getting tiresome.
Time to lock this charade 
1 Like
Stop reading it if it hurts you…
2 Likes
Yada yada yada.
Not me but it looks like the IDE does:
and for Desktop, you can have PushButton and DesktopButton in the same project.
I’ve seen such syntax throwing a compiler error (timer1 has no member “RunModes”) because the class must be used instead of an object. If you’re sure your example compiles, then I don’t know the difference of context.
I have been using the product for over 20 years, and I have the sense that at times it has worked and other times not- but my recollection on the is fuzzy… it may be it autocompleted but did not compiled or teh other way around … (don’t know if that is different IDE versions or different constants)…
It would help if always worked that way for sure…
But to be safe I got into the habit of using the class name… I’m one who does not like code to either be too verbose or too cryptically short…
At least for Desktop, I think in general, API 1 got that about right
-Karen