mcStandaloneBuilder b1 posted

[Wilhelm Sanke]

On Sun, 03 Jul 2011,  Ken Ray wrote:


> Sorry Wilhelm, misread your post - ignore what I said in my previous 
> post to
> the list.


Not at all, Ken. Your hint to the Livecode tab in the new "preferences" 
was new information for me, as it places the path to the preferred 
Livecode version then automatically into the field "LiveCode 
Folder/Bundle" of the SB.

> > My proposal is to allow to point to the "runtime" folder only, which
> > could be copied into the Metacard folder. This would mean that you need
> > not have both the full Metacard and Livecode installations on the same
> > computer (for example on a laptop).
>
> That's the rub... even if the LC SB worked perfectly, it would still be a
> pain to develop in the MC IDE and then have to switch out to LC in 
> order to
> build a standalone.
>
> We're trying to accommodate those that use MC *and* LC as well as those
> using MC only, so we should come up with a good way to do that; 
> pointing to
> only the Runtime folder might be a way to do it...

Thanks for agreeing here, and maybe we could have both options.

> Ken Ray


I want come back to my question about "required" and "optional" fields 
in the SB (in my last post):

The SB of our old MC IDE 3.0.0b has a impressing simplicity:

To successfully build a standalone only *three* selections have to be 
made. You have to select the source stack ("Stack name"), then the 
"Metacard engine" (which two years ago was already the path to this 
single file "standalone" (on Windows)), and finally a "Standalone file 
name" for the new standalone to be built.

Then you press button "Build" and get the message "Standalone built 
successfully"

Especially for quick builds in between during a development such a 
simple procedure (only on the surface of course) is important and 
useful, more detailed information about a standalone can then be entered 
under "Set Windows Version Info.." and "OSX settings" (with "file 
version", "OriginalFilename" etc. etc.)

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".

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". -

I am wondering what the meaning of this message could be. 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"

It seems to me that "Livecode 4.6" is a remnant of an earlier build 
inside Livecode. But that does not explain, why and how the standalone 
was created nevertheless and why it doesn't run?

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.

To sum it up: About four hours for the first two explorations of our new 
Standalone Builder, some insights - including looks at the structure of 
the scripts - and at least one really working standalone.

All in all a positive achievement.

Best regards,

Wilhelm Sanke