Best practice for managing two code versions

[Mike_D]

@Tim_Parnell

You can check, the Save As dialog will either have a Format popup menu or it won’t. Select “Xojo Project” if you can, otherwise it means they changed their mind about the “Lite gets source control” announcement.

Also note that if the IDE has lost track of your licenses, it won’t show all options.

If you think this has happened, From the Xojo app menu choose License Keys / Update

[brian_franco]

And also from a recent post reply from Alyssa Foley:

Xojo licences disappeard

Alyssa Foley Xojo, Inc.

1d

We ask anyone experiencing unexpected behavior with their license activation to share those in Issues so they can be looked into. As to the case Tim says he remembers but can’t find, I also cannot find anything like that, and @William_Yu can’t either. We’d love to fix any trouble users experience with licensing asap, but we need an Issue number with some details in order to reproduce it and begin an investigation. If you have filed or followed an Issue about this, please send it to me at hello@xojo.com.

[C_L_Hinkle]

(I’m the one Alyssa was helping … my license kept disappearing. We solved it this morning by deauthorizing the laptop on the website and then updating the license in the Xojo.)

[C_L_Hinkle]

I recognize that you can’t share the objects.

But I was thinking if the code references winWhatever.txtOverlap.yada-yada in the Desktop code, then I can use the same function in the iOS version if the iOS canvas in that project is also called winWhatever.

[brian_franco]

@C_L_Hinkle

glad you got it resolved

but just in case anyone else runs into a unexpected license problem behavior

[Tim_Parnell]

@C_L_Hinkle

But I was thinking if the code references winWhatever.txtOverlap.yada-yada in the Desktop code, then I can use the same function in the iOS version if the iOS canvas in that project is also called winWhatever.

I did briefly describe the answer to this, but I’ll explain further.

@Tim_Parnell

when done correctly, that class wouldn’t need to know whether it’s an iOS/MobileCanvas or DesktopCanvas that’s drawing because the Graphics object is cross platform abstract.

To expand, when shared code is properly designed, it doesn’t need to know the names of items. What you’re describing is spaghetti code. I can’t comment on how you’d put that in an external item because I never would and my opinion is that you never should.

---

Update:

Circle back to the idea I mentioned above, where Shared Code refers to a Preferences module. It needs to know NOTHING about the project it’s being used from internally. Where necessary (like for loading which specific preferences file), the “parent” project passes information as parameters to the Preferences Module.

The Preferences Module would never need to know that the settings window is named winSettings because winSettings loads the preferences OUT of the module, it doesn’t have the module send the preferences IN to the window.

It also reiterates the idea that you cannot share UI between Desktop and iOS/Mobile projects. winWhatever.txtOverlap is UI, is it not? winWhatever must be responsible for its own UI, but can load whatever shared logic is available by myOverlapDrawingClass.

There are some compiler constants that can let you make what some people call “clever” designs, but you could never make a property in an External Item a UI control. The more you dig, you’ll eventually find the “workaround” for that is to use Variants

#TargetDesktop
#TargetMobile
#TargetWeb

[Mike_D]

By the way, if anyone is interested in the normal Xojo Text format being used for External items (instead of requiring the Xojo XML text format) there’s a feature request for this: https://tracker.xojo.com/xojoinc/xojo/-/issues/3624 Dates to the year 2008, but it’s still open.

Please thumbs up it if you care about this issue.