I am working on a project containing, amongst other items, a UI and a language parser and interpreter. Due to the complexity of developing and testing the language interpreter, I have created a second project with all the language work so it can be developed and tested independently from the main codebase.
I’ve reached the point in the project where it is time to integrate the language work into the main app. However, I expect to still do some development on the language stuff, and it might be best to do this in the language project. There are nearly 250 code files in the saved project.
Is there a safe way to share these classes between the projects? I’m well aware that Xojo supports loading a class into multiple projects, but I’ve run into weird issues with that in the past, and it’s been a while since I’ve had to do this, so I thought I’d ask what the current best practice is here.
I noticed that by default, a Xojo project is saved in such a way that the project structure is represented as files and folders on disk. Is it safe to simply option-drag items from one project folder into another project to load them as external items?
Yes, except I think it’s option-command-drag from Finder to the project (more info here, including whether you’re on Windows).
I don’t things have changed much. There’s still limitation as far as nested Modules and/or Classes go, but individual items are fine. Plus, changes in one project does not always reflect in the other project right away, but other than that I find the files to be safely managed. Other limitations are that the External Item has to be saved as either an XML or Binary file (no text format), and you can’t use the duplicate context menu command on properties or methods.
Alternatively you could use git submodules, which is where you have one project (and it’s git repo) nested inside the other project (where the nested git folder is “ignored” by the parent repo).
I’ve used git submodules with Xojo projects before and found it a better experience as far as the Xojo IDE goes, because you “import” the nested classes from the other project rather than treat them as an External Item, so it’s like managing two independent projects. But it is more work on the git side of things, of course.
After having employed both methods with some of my projects, I’ve settled on just using External Items. It’s generally less maintenance as long as you understand the limitations.
Which format do you use? I’ve been using external items for a long time. xml for the last half dozen years or so and binary for a long time before that. I never ran into issues. I only make sure to edit a common class in one project and then reload the other projects if needed.
One other very useful (to me at least?) tidbit, is the attributes “tab” in the inspector. Which, along with #Pragmas, allows me to keep an entire copy of the shared libs in any project type without issue.
For example this is for a special dialog invoking class, which would never be used in console app (obviously?)
Additional notes on making code changes to the shared library code:
Though it seems to work better in later versions of Xojo, I don’t trust the IDE to auto-update external classes in Project A when they’re being changed in Project B. (which is, I’m sure, a hard task; especially given the IDE supports undo)
So if I need to make a change in a shared library, I always:
close all projects
open a project which needs something changed with the shared libraries
make my changes and test them
save and close the project (to avoid accidental quirks when using Undo
Minor update: you cannot import (and keep external) an item that hasn’t been made external. For example, if you dig into a project’s folder structure and try to import-as-external the files that you find inside, they are imported and made internal.
