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
com/user/SendEmail.jtp?type=node&node=4710301&i=0>>
> 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. For ecample, I set
y 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 wrote:
>
> Hi all,
>
> Various tweaks to the standalone builder seem to have broken the way the
> savingStandalone message is
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
guess what the part
> will be for each OS. Most of the time we can guess correctly, but if
> that ever changes we need to guess again. If we just had the complete
> path to the folder containing the freshly-build executable we'd be done
> with guessing altogether.
>
> Middle
and added a
platform param to standaloneSaved as proposed for savingStandalone, and
if that param was also the exact name of the target subfolder, I'd be
quite happy.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
__
omated processes, hard to beat the simplicity of a single integer
> value.
>
> But I can appreciate that some may not maintain both a version number
> and a build number, and it's not my place to require that they do.
>
> So I'm not opposed to any params sent with a savin
my place to require that they do.
So I'm not opposed to any params sent with a savingStandalone message
that work well for most folks. The platform distinction is a must, and
I'd love to have the destination path, but beyond that I can take care
of my own needs well enough.
--
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
if there was an additional parameter to indicate
that several standalones were being built at
once. Even if it was as crude as:
savingStandalone "Windows", 1, 3
savingStandalone "iOS", 2, 3
savingStandalone "Android", 3, 3
That would allow work to be don
n 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 wrote:
>>
>> Hi all
ter to indicate
> that several standalones were being built at
> once. Even if it was as crude as:
>savingStandalone "Windows", 1, 3
>savingStandalone "iOS", 2, 3
>savingStandalone "Android", 3, 3
>
> That would allow work to be do
saveStackRequest message) and clear it for the standalone(s) when built.
As noted, I could code around it, or, as I consider this, I realize in
this specific case where I am clearing a property, repeated calls of the
savingStandalone message would not matter. In another I add a date and
time stamp
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 bui
ssage with
parameter to indicate which platform was being built for, if there was an
additional parameter to indicate that several standalones were being built at
once. Even if it was as crude as:
savingStandalone "Windows", 1, 3
savingStandalone "iOS",
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
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
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
t;
> > On Thu, Feb 9, 2012 at 10:19 AM, Klaus on-rev >wrote:
> >> Hi friends,
> >> there is this handy "savingStandalone" message which does not come with
> >> any parameter.
> >> Is there a way to get to know for what platform the current sta
nts
> of the individual platform folders within that folder.
AHA! So there IS in fact a parameter, but this is undocumented!
Great, thanks a lot!
> Pete
>
> On Thu, Feb 9, 2012 at 10:19 AM, Klaus on-rev wrote:
>> Hi friends,
>> there is this handy "savingStandalone
, Feb 9, 2012 at 10:19 AM, Klaus on-rev wrote:
> Hi friends,
>
> there is this handy "savingStandalone" message which does not come with
> any parameter.
>
> Is there a way to get to know for what platform the current standalone is
> being build?
> I would take diffe
Hi friends,
there is this handy "savingStandalone" message which does not come with any
parameter.
Is there a way to get to know for what platform the current standalone is being
build?
I would take different actions for Mac resp. Windows standalone, but probably
I'm out of luc
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
evengeband
On Dec 15, 2010, at 7:57 PM, J. Landman Gay wrote:
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
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 intercept
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
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
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 up
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
http://www.sonicbids.com/MollysRevenge
http://www.myspace.com/mollysrevengeband
On Dec 13, 2010, at 3:59 PM, J. Landman Gay 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
e 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 modal windo
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 "Band
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 dialogDa
37 matches
Mail list logo
