bobsneidar at iotecdigital.com
Tue Nov 15 18:37:21 CET 2016
I just compiled for Mac only and the dialog about the open library does not appear. However I am getting this runtime error:
Executing at 9:35:40 AM on Tuesday, November 15, 2016
Type: Handler: error in statement
Object: stack '/Applications/Forms Generator.app/Contents/MacOS/Forms Generator'
Line: go invisible to card 'Main' of stack 'Forms Generator'
Line Num: 12
Remember this compiles on 8.0.1 some something dramatic has changed. And not in a good way.
> On Nov 15, 2016, at 09:30 , Bob Sneidar <bobsneidar at iotecdigital.com> wrote:
> Okay my standalone building bug is probably related to this one. I can provide any testing and feedback you need on this. For instance, I just quit all versions of Livecode, opened LC 8.1.2 rc1, ONLY opened the splash stack and NOTHING ELSE, tried to compile, and I get this dialog:
> A stack with the same name as the one you
> are trying to load is a lready open.
> Before loading
> Projects/Forms Generator
> 8/Libraries/sql_yoga.livecode, what do you
> want to do with stack:
> Projects/Forms Generator 8/Forms
> Note the WINDOWS in the second file path. It looks like after it's done compiling for Windows, it is leaving the copied library in memory (why it would have that copy open I do not know), so that when it goes to comile for Mac a second library is open in memory and it wants to save/purge it. As I mentioned this started happening with 8.1.1.
> Bob S
>> On Nov 15, 2016, at 01:45 , Ali Lloyd <ali.lloyd at livecode.com> wrote:
>> Hi all,
>> Various tweaks to the standalone builder seem to have broken the way the
>> savingStandalone message is supposed to work
>> I have submitted a pull request that fixes it - the only wrinkle might be
>> that it reintroduces the following bug:
>> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
>> savingStandalone message gets sent for each build platform.
>> Now, my personal view is that that is how it should work, provided the
>> stack state is restored before building for the next platform. It allows a
>> more fine-grained build step where, if we added suitable parameters to the
>> message, you could for example ensure substacks with platform/architecture
>> specific resources were not included in the standalones where they are
>> My question to you is the same as I asked Lyn Teyla in the above report:
>> Would the following behavior be a problem for your use case, and if so why?
>> store stack state (*)
>> repeat for each target architecture
>> dispatch saving standalone message
>> modify stack for per-arch settings
>> deploy stack
>> restore to state in (*)
>> dispatch standalone saved message
>> end repeat
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode