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 Hint: openStack Comments: Remember this compiles on 8.0.1 some something dramatic has changed. And not in a good way. Bob S > On Nov 15, 2016, at 09:30 , Bob Sneidar <[email protected]> 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 > /Users/bobsneidar/Documents/livecode > Projects/Forms Generator > 8/Libraries/sql_yoga.livecode, what do you > want to do with stack: > /Users/bobsneidar/Documents/livecode > Projects/Forms Generator 8/Forms > Generator/Windows/sql_yoga.livecode, > libSQLYoga? > > 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 <[email protected]> wrote: >> >> Hi all, >> >> Various tweaks to the standalone builder seem to have broken the way the >> savingStandalone message is supposed to work >> http://quality.livecode.com/show_bug.cgi?id=18778 >> >> 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 >> irrelevant. >> >> 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 >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
