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

metacard mailing list

Reply via email to