I don’t know if anyone else has this problem… the quarterly updates are nice. New features and patches arrive much more quickly in a continuous development type release cycle. That said… I have found that over the years… there have been significant enough changes that my older code which may “require” a one line update won’t run correctly under the current framework. Sometimes it’s a matter of the plugin as well. So I need to tag each of my programs to indicate what they were built with and which version of which plugins were used. I try to move programs forward…but sometimes the limitation in on the install base. Code for old versions of linux where newer linux compiles require newer libraries not available for those old linux installs. I find that I have most every version of Xojo installed back to 2014 Release 1.1 – and I’m using 25 GB of drive space to keep all these combinations of app + plugins available. On one hand I’m super happy that different releases can run concurrently. This is often troublesome in some other IDEs. I find I’m often working on two projects at the same time have two different versions of the IDE running concurrently. Perhaps I just need to create corresponding project directories. Otherwise it’s kinda hit an miss when I open a project to figure out which version I need to develop in. Anyone else experience this?
If you are on a Mac, you could use Christians Quick Look Plugin for the Xojo Version Tag: http://www.mbs-plugins.de/archive/2018-05-10/Check_our_QuickLook_Plugin_for/monkeybreadsoftware_blog_xojo
Or use only one Xojo version for all your projects ?
I have a project originally written and debugged under RS 2012 with MBS from the same era. Moved it to Xojo 2017r3 and MBS 175 with only a few minor changes (thread accessing UI and some integer type issues); all works under 2018 versions, and I can still open, compile and run, edit, and save it it under RS and then go back to Xojo if I feel like it. Pretty sweet.
Yea, it depends on platform. Some of my routines run on Linux…and some have to run on CentOS 5.5. That district version doesnt support the Linux libraries required by the current version of Xojo compiles for Linux.
Create an app ( in Xojo of course ) which allows you to drop a Xojo project on it. The first time, have it ask which version of Xojo it uses and store that in a sqlite database. From then on when you drop it, it can launch the correct ide for you. If its something that you just had open, you could also have it scan the plugins folder to get the names and a hash of the plugins that were used with it and then be able to later copy in the right ones ( and remove the ones from the previous run.
FWIW, If your projects are stored as text or xml, the ide version is readily available near the top of the file.
I considered I might have to create an app to organize and track my apps. That said, I tried Sashas suggestion using Christians quick look plugin. ( its completely free and doesnt even require an MBS license). It doesnt require a Xojo plugin. Its a plugin for quick look and it works great! I do licence the MBS plug-ins, but its really great that Christian is involved with the community like this.
This is a project I was working on the past view months. It reads the Mac OS X version at least required to run an application, and supports some document types to read what version of an application is at least required to open it:
The code snippet to get the Xojo version required to open a project file reads as follow:
dim tmp,tmp3,VersionFound as String
dim LsMinFound as Boolean
dim a,i,l,d as Integer
dim LsMinStr as TextInputStream
LsMinFound=False
VersionFound=""
f=GetFolderItem(PathToGame)
if f <> nil then
if f.Exists then
if (right(f.Name,6)=".pages") or (right(f.Name,8)=".numbers") or (right(f.Name,4)=".key") then
MsgBox CantHandleiWorkFilesText
elseif (right(f.name,4)=".app") or (right(f.name,4)=".App") then
...
elseif (right(f.name,4)=".PDF") or (right(f.name,4)=".pdf") then
...
elseif (right(f.name,4)=".rbp") or (right(f.name,4)=".RBP") or (right(f.name,20)=".xojo_binary_project") then
LsMinStr=TextInputStream.Open(f)
tmp=LsMinStr.ReadLine
if debugbuild then MsgBox" Debugbuild: tmp="+tmp
i=0
l=0
i=InStr(tmp,"PSIVStrn")
l=InStr(tmp,"Ver1Strn")
if (i <> 0) and (l <> 0) then
d=0
d=instr(tmp,"20")
LsMinFound=true
tmp3=mid(tmp,d,8) //Get the Xojo version stored in the project file
if debugbuild then MsgBox "Debugbuild: tmp3="+tmp3
if val(Right(tmp3,1)) = 0 then
tmp3=left(tmp3,len(tmp3)-1)
end if
Window1.Listbox1(2).AddRow ""
Window1.Listbox1(2).cell(Window1.Listbox1(2).LastIndex,0)=f.Name
//tmp3 holds the version found between PSIVStrn and Ver1Strn
Window1.Listbox1(2).cell(Window1.Listbox1(2).LastIndex,1)=tmp3
end if
if LsMinFound=false then
Window1.Listbox1(2).AddRow ""
Window1.Listbox1(2).cell(Window1.Listbox1(1).LastIndex,0)=f.Name
Window1.Listbox1(2).cell(Window1.Listbox1(1).LastIndex,1)=DestMinPDFVerNotFoundText //"Not known."
end if
Window1.PagePanel1.Value=2
The main part in the code snippet are the lines that check for “PSIVStrn” and “Ver1Strn”, because the Xojo version number is stored in between. Then, the code looks for “20” and reads (“mid(tmp,d,8)”) 8 chars forward to get it.
This application doesn’t save the checking results nor does it organize and track the results.
Um… normally I try to refrain from pointing out issues with posted code. But yours could really be improved:
Booleans are initialized as false so that “LSMinFound” = false is not necessary. Ditto for integers.
Do the nil and exist check together and simply return when you don’t have a folderitem: If f = nil or not f.exists then return . Way simpler to read.
right is case insensitive .
Get the file ending with whatever method you can do. Then do a case on the file ending.
I maintain 4 versions of RS/Xojo on my development systems. I separate tasks under my Development folder as RS, XOJO13, XOJO16, and XOJO.
My only consistent “oops” is when I forget that I have an IDE version running and double click a project file with it opening in teh running IDE instead of the proper version.
Appreciate your hints. But this one, probably already set to value “true” from an earlier check?
Could set it to false at the end of the method.
And the combining of f=nil and f.exists, this is a good hint.
Nice hint about right, that could make a lot simpler code for compiling.