Properties with the same name

General Programming
,
1

@DavidCox
As mentioned own TOF there are a few options
One more
Create an interface that is compatible with all project type
Declare a SINGLE property that is the same type as the interface
Then create subclasses of the Xojo types and have them implement the interface
Then the code just deals with the interface regardless of platform
And the class, or other code, can create & set the property to an instance of the correct one per platform

There’s an example of this in the Preferences class in my Kitchen Sink project

see KitchenSink/Preferences.xojo_code at main · npalardy/KitchenSink · GitHub
and the three platform specific instances in KitchenSink/Starting Stuff/Preferences at main · npalardy/KitchenSink · GitHub

2

Developers now start finding workarounds for Xojo’s botched x-plat approach?
I wonder how long it will take until this breaks with a new IDE relase.

3

in my opinion the answer SHOULD be

 #if TargetWeb
Private Property theField As WebTextField  
 #elseif TargetDesktop
Private Property theField As DesktopTextField
#elseif TargetMobile 
Private Property theFieldAs MobileTextField
#endIf

or actually

Private Property theField As TextField   // THE COMPILER KNOWS
4

I’ll be the first to say the what their “strategy is” was in place when I got there
Different project types went in different projects
There was little commonality or sharing between them

AND I helped perpetuate that (web and iOS for instance)

It wasnt until after that time that I really started to realize that approach was fundamentally wrong headed

BUT it had so many years of usage that changing it would be an enormous undertaking
Not impossible - and I actually had a plan - but that never came to be

And now Android is likely to perpetuate it and exacerbate the problem even more

I’d LOVE to have a VERY long conversation with the dev staff about how to move away from “each project type is in its own project with little shared between them” but I doubt anyone there has the stomach for that

oh well …

So yes workarounds are found because thats the only way you can move forward
Is it nice ? hell no !
Is it useful ? as a design pattern its not horrible

5

That would be nice except Xojo has no way to put an #if around a property :slight_smile:
But it DOES Know the combat flags setting for them so that could work
But I doubt anyone will make the changes to the IDE to allow it as they are more extensive than they might seem at first glance

The second would be much nicer but, the reality is, since they renamed everything to have unique prefixes thats not going to happen
And what a pain all those prefixes are - makes autocomplete so much more useless
Have to type “desktop” then the first letter of the thing in a desktop project to NOT get EVERY thing prefixed DESKTOP
ARG !!!

6

I realize that (another shortcoming in my opinion as well)… which is why I said “SHOULD” :slight_smile:

7

I’m not sure. I still think trying to pack everything together would be a mistake. The capabilities of controls are vastly different on each platform. Making them common would be a huge, messy, and unsatisfying undertaking.

We can already choose which project types a property exists in. Just let the IDE name properties (and other parts) the same, and throw an error at compile time if there is a problem. Then you could easily have three properties with the same name, each with different non-overlapping compatibility.

And then allow multiple targets in the same project, so we can compile our Desktop, Web, and Mobile versions from a single project. Granted, you’d have to rename project compatibility to target compatibility, but the logic wouldn’t change.

I think this would be a much more practical approach than trying to squash all the controls together.

8

Not sure where “squash all the controls together.” came from ?
that isnt what I said in that at all
in fact its nearly identical to what you wrote
make everything (classes, modules, code, properties, etc - literally everything in USERS projects) have compat flags and only render out those things “compatible” with the target being compiled

but once you do that there’s no problem having an iOS exe, web exe, desktop exe and console one all from the same “project” since combat flags will sort out what goes with what

that does entail some decent side changes to the IDE to do that, and also a relaxation of a few things like naming items on disk since if you had 3 different “FooClass” classes with different compat flags you need a way to distinguish them on disk so one doesnt overwrite the other

And the IDE has other issues like autocomplete that would need adjustments

Its NOT trivial to just do this

BUT its probably where things should have gone oh so long ago
:man_shrugging:

9

Ah, I misread then. Sorry.

11

No problem

I go back and forth about “a button is a button is a button” and lifting out base common properties like caption left top width & height into a “super” (… maybe there are more ?)

But maybe they dont even need to be subclasses of anything common across the frameworks

If the desktop framework has “Button” thats only compatible with desktop, web has “button” thats only compatible with web, and mobile has “button” thats only compatible with mobile then they can be distinct supers - one per framework (this can work as I’ve done something like this in a client project)

And you’d get the right one at runtime since there would only be one in the framework linked in
I’m sure from 10000 feet there are things I’ve overlooked
And yeah this would drive autocomplete as it existed nuts since it would have to know ore about combat flags etc. Either way it seriously needed a rewrite to look things up the same way the compiler does

But it would make working in multi target projects easier - almost without making single target projects any different
Again, this is 10000 foot so I’m sure there are details overlooked

I just dont think such giant changes are ever likely to happen until/unless the entire IDE is completely rethought & the way projects are stored on disk is altered as so many things are intertwined
And if they foo pursue any of this they really ought to think about a format that makes using git sub projects “just work”

details details details

1 Like
12

Or use a Preference (sorry checkBox for Desktop or Not Desktop)…

But the LR displays every command regardless the “kind” of project… A PopupMenu (or RadioButton Group) in Settings will help me… (avoid displaying Web or Mobile help if I do not want them).

In short: solutions exists.