Just discovered that the reason for this is that the compiler somehow changed
the path to the mainstack in the Stack Properties Stack Files. What the...??? I
reset the path to the main stack and now I can compile.
Bob S
On Nov 15, 2016, at 09:37 , Bob Sneidar
mailto:bobsnei...@iotecdigital.co
Hi all
Ali I would find it really useful if we could set a build number for iOS builds
inside the plist file where I’m using the 'external test’ functionality in
TestFlight
I normally use my own way of setting and recording build numbers - and I’m
happy to carry on doing do. But where there’s
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
On 15/11/2016 22:48, Paul Dupuis wrote:
On 11/15/2016 3:41 PM, Ali Lloyd wrote:
I was thinking a parameter array would be better than many additional
params. That way, additional info is cheap.
So currently the proposed params are:
- current build platform
- current build target/architecture (t
On 11/15/2016 3:41 PM, Ali Lloyd wrote:
> I was thinking a parameter array would be better than many additional
> params. That way, additional info is cheap.
>
> So currently the proposed params are:
> - current build platform
> - current build target/architecture (to disambiguate between 32 bit/64
Ah yes, I had unthinkingly just corrected the folder parameter to
standaloneSaved, but I will have to do it in the array data for backwards
compatibility I suppose.
On Tue, Nov 15, 2016 at 8:51 PM Richard Gaskin
wrote:
> Ali Lloyd wrote:
>
> > I was thinking a parameter array would be better th
Ali Lloyd wrote:
> I was thinking a parameter array would be better than many additional
> params. That way, additional info is cheap.
>
> So currently the proposed params are:
> - current build platform
> - current build target/architecture (to disambiguate between 32 bit/64
> bit/both)
> - tota
I was thinking a parameter array would be better than many additional
params. That way, additional info is cheap.
So currently the proposed params are:
- current build platform
- current build target/architecture (to disambiguate between 32 bit/64
bit/both)
- total number of standalones to build
-
Ben Rubinstein wrote:
> If you're proposing that the LC IDE maintain a build number for every
> stack, that might save a bit of effort for some sub-set of the
> audience which uses build numbers; but for those who for whatever
> reason use build numbers or similar in some scheme incompatible with
On Tue, Nov 15, 2016 at 9:14 AM, Richard Gaskin
wrote:
> I'm less certain about the count params, and would favor a build number.
> But that would require that all of us use build numbers, and perhaps some
> don't, so I'm not opposed either.
I would like to see flexibility on this. Personally
On 15/11/2016 17:14, Richard Gaskin wrote:
I'm less certain about the count params, and would favor a build number.
But that would require that all of us use build numbers, and perhaps some
don't, so I'm not opposed either.
To be clear, which I may not have been, my proposal was that the parame
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'
Lin
Ben Rubinstein wrote:
> Paul, I'd think that your needs (which certainly overlap with
> mine...) could be met by adopting Ali's suggestion in that report
> of a single message with parameter to indicate which platform was
> being built for, if there was an additional parameter to indicate
> that
Ben,
Your suggested model with the parameters would work just fine for me. I
like it!
Ali
Different projects of mine do different things, but generally, for some
of my projects, I grab a stack custom property that represented a
incremental counter (which is basically incremented by 1 on every
sa
Thanks for the feedback Paul. How is your build number increment
implemented?
On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis wrote:
> I make use of the savingStandalone message in a few projects. Generally,
> I would prefer a single message regardless of the number of platforms I
> am building for.
I seem to recall that one A Lloyd made a sensible suggestion for rationalising
this area:
http://quality.livecode.com/show_bug.cgi?id=18371
Paul, I'd think that your needs (which certainly overlap with mine...) could
be met by adopting Ali's suggestion in that report of a single message with
p
I make use of the savingStandalone message in a few projects. Generally,
I would prefer a single message regardless of the number of platforms I
am building for. For ecample, I set a incremental "build' number on
savingStandalone and I would want that build number to be the same for
all platforms b
17 matches
Mail list logo
