> Our new SB could maybe be considered to possess a similar simplicity,
> but it is surely not obvious, unless of course you know which entries
> are required.
> After a lot of trial and error - yesterday and today - I think I found
> out the minimal requirements to build a standalone (I am though not
> sure, whether I am 100% exact here, but they seem to work; ten minutes
> ago I have been finally able to build my first working standalone, but
> we do not get a concluding message after an achieved build like with MC
> SB 3.0.0b):
> - select "Source Stack"
> - "Save Stack" is *not* needed for the build, probably only useful for
> storing the new custom properties in the source stack, but for that
> purpose *after* the build process.
> -select "destination Folder"
> - select "LiveCode Folder/Bundle"
> In the "General" Tab
> - enter "App Name" (name of the new standalone)
> - enter "Version"
> - enter "Builder Number" (really reqired?)
> In the "Windows" tab
> - add "File Version"
> - add "Product Version".
OK, let's take this one at a time as it relates to a "quick build" (i.e.
brand new stack):
"Source Stack" currently is automatically filled in for you *if* the stack
has any standalone settings stored with it. I think it should just use the
topStack (unless Richard wants to chime in here).
At least one "Build For" checkbox must be checked. Perhaps the SB should
automatically check off the current OS's checkbox for a brand new stack.
"Destination Folder" is needed, but once again, perhaps it can default to
the current location of the stack.
"LiveCode Folder/Bundle", if set in Preferences, will automatically be
filled in for you in the SB.
"General Tab": All you should need to fill in is the "App Name" and "Version
Number" field - once you exit the Verison Number field, it automatically
sets the File Description, File Version and Product Version fields on the
Windows tab (as well as the Short Version, Long Version, and Get Info fields
on the Mac OS X tab).
So if changed to meet the above concepts, for a quick build you'd need to
just enter the App Name and Version Number.
> As a result of all my endeavours I have now got two extra folders in my
> destination directory, namely "Version" and "Version 1". Folder
> "Version" is empty, "Version 1" contains two subfolders "Build" and
> "Build 1". "Build" also is empty, "Build 1" eventually contains folder
> "Windows" with the three standalone files I managed to create in these
> two days. All indeed bear their "App Names" I had chosen in the
> "General" tab, but two of them refuse to run and throw an error
> "Standalone origin mismatch". -
When you build with the SB, a subfolder of the Destination Folder is created
based on the version number in the "Version" field, and a subfolder of the
Version folder for the build number. So if the version is "1.0" and the
build number is "1", and the app name is "Test", when you build it you get
this in the Destination Folder:
Apparently if you leave the "Builder Number" (should be "Build Number")
field empty, it will create a folder based on the Version field and a
subfolder just called "Build", but will then throw an error, giving you:
If you then put "1" into the field and re-build, it creates the "Build 1"
folder and puts the standalone into there:
If you leave the Version and Build Number fields alone and change the name
of the standalone to "Another Test" and hit Build, you'd have this:
> I am wondering what the meaning of this message could be.
I can't help with that one... it must be thrown by the LC engine itself.
> As I had
> already reported yesterday, one of the non-running standalones has
> deviating entries in its ""cRevStandaloneSettings" that are created
> during the build process
> "Livecode 4.6.1" for "_GEN_EngineFolder"
> but "Livecode 4.6" for "defaultBuildFolder"
Interestingly, I don't have a "defaultBuildFolder" value in my custom
property set for a fresh build.
> I recommend to use something like "cMCStandaloneSettings" in the future
> to avoid such conflicts.
> The second non-running standalone, which throws the same error message,
> does *not* have such conflicting "cRevStandaloneSettings", in fact,
> there are none at all, having seemingly disappeared later somehow.
One thing to keep in mind is that all of the settings you make in the SB
don't get written to the stack you're building the standalone from unless
you click the "Save Stack" button in the SB.
So perhaps if you delete the cRevStandaloneSettings custom property set and
then re-save the settings by clicking the "Save Stack" button in the SB?