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
Hi Pete,
Am 09.02.2012 um 20:15 schrieb Pete:
> No, different message Klaus - you were using "saveStandalone" which has no
> parameters, but there's another message "standaloneSaved" that has the
> parameter I mentioned.
Ah, yes, I see, my fault.
> But you don;t get that message until after t
No, different message Klaus - you were using "saveStandalone" which has no
parameters, but there's another message "standaloneSaved" that has the
parameter I mentioned. But you don;t get that message until after the
standalone has been saved so it may not be useful to you.
Pete
On Thu, Feb 9, 201
Hi Pete,
Am 09.02.2012 um 19:31 schrieb Pete:
> Hi Klaus,
> Depending on what it is you need to do, you might be able to use the
> standAloneSaved message. It comes with a parameter containing the path to
> the folder than the standalone was saved in so you can tweak the contents
> of the indivi
Hi Klaus,
Depending on what it is you need to do, you might be able to use the
standAloneSaved message. It comes with a parameter containing the path to
the folder than the standalone was saved in so you can tweak the contents
of the individual platform folders within that folder.
Pete
On Thu, Fe
No problem Jacquie, I'm always grateful for your assistance.
Pete Haworth
On Dec 15, 2010, at 9:44 PM, J. Landman Gay wrote:
On 12/15/10 11:17 PM, Peter Haworth wrote:
I guess I have to wonder why that message is provided if it's not
safe
to do certain things, or at least what should be avo
On 12/15/10 11:17 PM, Peter Haworth wrote:
I guess I have to wonder why that message is provided if it's not safe
to do certain things, or at least what should be avoided. I'll figure
something else out.
My mistake, I didn't realize it was documented. So it's probably okay to
use, but I'm not
I guess I have to wonder why that message is provided if it's not safe
to do certain things, or at least what should be avoided. I'll figure
something else out.
Pete Haworth
http://www.mollysrevenge.com
http://www.sonicbids.com/MollysRevenge
http://www.myspace.com/mollysrevengeband
On 12/15/10 5:30 PM, Peter Haworth wrote:
So what is safe to do in savingStandalone? I set a different custom
property of the main stack to today's date in my savingStandalone
handler and that works fine.
I don't know, sorry. I never use it. I'm not comfortable intercepting
any of the internal
So what is safe to do in savingStandalone? I set a different custom
property of the main stack to today's date in my savingStandalone
handler and that works fine.
Pete Haworth
On Dec 14, 2010, at 3:19 PM, J. Landman Gay wrote:
On 12/14/10 4:22 PM, Peter Haworth wrote:
I'm still trying to f
On 12/14/10 4:22 PM, Peter Haworth wrote:
I'm still trying to figure this out. Here's the latest twist - the About
dialog in the standalone, which uses the custom property, displays the
correct version as entered in the prompt dialog during savingStandalone.
But the custom property I see in the I
I'm still trying to figure this out. Here's the latest twist - the
About dialog in the standalone, which uses the custom property,
displays the correct version as entered in the prompt dialog during
savingStandalone. But the custom property I see in the IDE doesn't
get updated.
I seem t
Hi Jacquie,
Sorry,
I didn't update the code snippet. I put the dialogdata into a local
variable right after coming back from the modal prompt. I want this
process to be automated so that's why I don;t use the message box -
I'd forget to do it! I could use an "ask" dialog, it's just that m
On 12/13/10 7:51 PM, Peter Haworth wrote:
Hi Jacquie,
I'm certain the prompt handler is returning the correct value - I put an
answer information in it right before the set statement and it showed
that the dialogdata had the value I keyed into the prompt form.
Ask and answer dialogs change the
On 12/13/10 7:07 PM, Peter Haworth wrote:
Thanks Jacquie. It's possible to change the version property? The
dictionary makes it sound like that is the version of LC, not a
user-defined standalone app version.
Right, the built-in "version" function returns the engine version. You
can store your
Hi Jacquie,
I'm certain the prompt handler is returning the correct value - I put
an answer information in it right before the set statement and it
showed that the dialogdata had the value I keyed into the prompt form.
Pete Haworth
http://www.mollysrevenge.com
http://www.sonicbids.co
Thanks Jacquie. It's possible to change the version property? The
dictionary makes it sound like that is the version of LC, not a user-
defined standalone app version.
Pete Haworth
On Dec 13, 2010, at 3:59 PM, J. Landman Gay wrote:
On 12/12/10 7:08 PM, Peter Haworth wrote:
I have the foll
On 12/12/10 7:08 PM, Peter Haworth wrote:
I have the following code in a savingStandalone handler in the script of
my main stack:
go to card "FieldPrompt" of stack "Prompts" as modal
if the dialogData is not "Cancel" then
set the BandTrakVersion of stack "BandTrak" to the dialogData
end if
The
34 matches
Mail list logo
