The way I outlined, if I remember correctly, also allows for modules with embedded classes or other modules, while it doesn’t work as expected otherwise.
As I said, though, I’ve not had a need to do this in quite some time, so it may be different and YMMV.
It looks like modern Xojo entirely blocks making and adding an external module with child classes/modules. If you try, you get messages. You can export the module, but you cannot then import it in to a new project as an external.
I noticed that too, when I was trying to incorporate your excellent GraffitiColors module as an External Item to some of my projects. I had to rework things to put the parts I wanted all as direct child objects from the one parent Module. Then it worked fine 
Xojo externals are useful up to a point
And then when they turn out to not be you need to move to something else
For us that was day 1 and we’ve used svn externals since the first time we needed to share code between projects as they need to say in sync
I’m just suggesting for those than have the ability to use text projects that they should get used to using their version control system for this and retain more history in a usable form
YMMV
In the past I’ve used extrnals a lot and often and it is very helpful if you are working on projects alone or with restricted user groups with same philosophy and project spirit and knowledge. But this can become deadly if somebody changes something you are not aware of.
Since 2019 I’ve begun to move my objects and code snippets to an internal git Instance. I love https://gitea.io/ which is lightweight, blazing fast and easy for collaborative work with others.
git or svn can be run on a single machine quite readily regardless of whether you’re using macOS, Windows, or Linux
in case you need a nice UI for git: https://www.git-tower.com/
Well, native git support within XOJO would be Eastern, Birthday and Christmas in a single day.
heh … SVN ! reminiscent of the vi vs emacs wars 
I’d sure want it to be “pluggable” so you could select git, I could pick git OR svn depending on project etc
If a person could write a “Version control script” that the IDE could use that’d be almost ideal then it would be infinitely extensible by anyone for whatever version control system they used
And if there wasnt one installed then the IDE just acts like it does now
have you ever heard about using libraries ?
But Xojo has more importend work to do, like Android …
Boring that merely re-opening this makes it show up when it has no new content.
Patience, my friend. Patience.
For me, the external does not solve the problem.
For the simple reason that the objects are different when trying to use them on different platforms.
For example, a weblLstBox class cannot copy to iOSMobileTable. Notice that both objects are different.
The ideal thing for me, as Johann Kienbrandt mentions, is to use a class library.
I hope XOJO planning a class library where the team can save objects and share them. Without cross-project problems.
@TimStreater I appreciate your interest in this topic.
There (always | often) is another way or approach… and there will be new content for this topic. Stay tuned for a little surprise 
Shameless plug for a video tutorial I did recently (ish) on using external modules and classes in Xojo: Using External Modules & Classes - YouTube.
I use external classes all the time and they work well for me.
I hark back to the days when you compiled a number of modules and therebye created a library, against which you linked your programs, and the linker included modules as required from the library to make the executable.
That, to me, was always a good way to re-use code.
Hi, code reusable, one of the favorite topics of project managers for cost reduction.
Separating software is one thing, but then it needs coding guidelines, best practices and maybe a redesign and a good architecture to survive it.
For sure one could clone everything in separate branches. But this would make maintenance, bugfixing not easier.
BR Rainer
I enjoyed re-reading it. It’s an “evergreen” topic, and my old forgetful brain needs regular refreshers.
I’ve explained the approach we’re using in this Xojo Guest Blog Post: Xojo Projects in a MonoRepo
However, I don’t know if there is a “best practice”… I guess that depends on your project(s) and needs, as all possibilities have their pros and cons.
There is quite some information in this topic, and also the Blog shows both (dis)advantages of that approach.
The MonoRepo approach could also be used without a Version Control system.
An advantage of the MonoRepo approach is that everything is contained in a single folder (containing sub-folders of course; all files referenced relatatively), and can be moved around and to other Operating Systems without issues.
Not with what the Blog Post is showing - that’s using just the xojo text project format. All (even shared) code is considered an “internal item” for the Xojo IDE, while parts of the code/files (all in xojo’s readable text format; not binary or xml) are shared between several projects.
That works just fine with the MonoRepo approach described in the Xojo Guest Blog Post: Xojo Projects in a MonoRepo.
One example is Aloe Express (which consists of Modules with nested Classes in there) - works fine for us to share between multiple projects.
Sure… a MonoRepo is not ‘the’ solution for every collection of projects - but maybe something to consider.
I’m curious if we’re the only ones that are using “shared code” with Xojo Text Projects using a MonoRepo - at least I’m not aware that this approach has been explained on the forum before… So I hope this Blog Post has been helpful to some, food for thought to others.