I’m pretty sure you can use App.StageCode also, which is useful for adding beta testing code in development apps, without having to strip it out when releasing:
#if App.StageCode <= 2 then
// Do some logging or other debug only code.
#end if
Obviously libraries would be better if this was supported.
Any constant you happen to define, in fact.
Hmm, obviously my “truth” was that it should work thus, and so it did.
Wow, that’s a superpower!
The technique I learned from Norman was to have a module called BuildSwitches and a Boolean constant for features that were being tested. That way you could do something like this:
#If BuildSwitches.kProVersion or DebugBuild
... new pro version code that you're testing...
#EndIf
Then you can easily test in debug mode but not ship the feature until you’re sure it’s ready. Constants can easily be changed in build scripts too.
ConstantValue("BuildSwitches.kProVersion") = "true"
I tried with some custom controls. I don’t remember if I even lost some code.
The way I see it !!
A library is a file containing 1 or more methods in text mode.
Each application can decide which of the files have to be included in the application.
That will work for any operating systems, I think.
How would that be different from External items?
As far as I can remember the changes are not written back to the externals, they were done in the application.
Next app uses the externals were missing the changes.
Externals should be treated like app folders from a different location. What it needs is, let’s call it a project file to hold all those references to external libraries (could be more than 1) which should be treated like belonging to the app.
Any other app could include then those folders ( libraries ) in there app.
And that’s exactly what they are. You change it in one project and the next one you open has those changes. I have rarely seen it fail, and then only when I’ve done something stupid.
i don’t know if current xojo behave same but
i remember if you use menu file/collect project items…, xojo break the link to external files and copied it to the project. collect project items was necessary after you drag and drop icons or images to the project. if you not use collect project items, after reopen the project all new images was not found and it was really annoying.
Collect Project Items is essential to one’s sanity if you use externals, as it’s the only way to preserve a snapshot of the project at a moment in time, before changes to external items made while working on other projects change them.
Not only “the next one you open”, but projects already open will get the changes, too. I often have a number of projects open at once, sharing the same externals. Sometimes the IDE will refuse to allow changes to an external, in which case the project has to be closed and re-opened to enable editing again.
To get back to the original question, what are Xojo Libraries supposed to be?
I’m also still waiting for this information.
When they were originally conceived, they were a mechanism by which you could bundle code and assets together into a single entity to be shared between projects. I don’t remember if that included being able to compile them to prevent hacking or not.
Whatever they ultimately are, they need to be able to contain anything that can go into a project. Modules, windows, graphics, sounds, whatever. Ideally even build steps, but that would be a challenge. I could imagine a system where the step is added to the end of the list and the developer would move it to wherever is appropriate in their chain.
Compiled would be nice, but I don’t think that’s realistic.
The question is… do we get a package manager with this? Because I feel like we should get a package manager with this.
Unless some specific tailored build steps, just for such libs, with domain limitations, like acting only inside the limits of that package, as if it was like an entire separate project by itself, and firing before any actual project build steps. Without isolation it would be Impractical, due to possible project build steps conflicts and probably some security issues.
I bet they could add a “property” to assets which designated a destination directory though, like “Frameworks” or “Libraries”. That would solve the CopyFilesStep problem.
Are libraries far enough along now to share information as to exactly what they are? I’m really tired of not being able to share external modules containing classes. I’m hoping libraries will solve that problem.
There is some interesting information in the following video that Geoff presented in the MBS conference this year:
