savingStandalone message

[Paul Dupuis]

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
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 into a property of the standalone - ideally the same date &
time for all the platforms I am building for (which in that case is just
Windows and OSX)

As I noted, any of the above can be coded to work with a
savingStandalone message for each platform, so it is not like the
proposed change would change anything that could not be fixed.


On 11/15/2016 8:49 AM, Ali Lloyd wrote:
> Thanks for the feedback Paul. How is your build number increment
> implemented?
>
> On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <paul at researchware.com> 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 a incremental "build' number on
>> savingStandalone and I would want that build number to be the same for
>> all platforms built for. If the message was sent for each platform I
>> suspect I could come up with some what to still do this, but the code
>> complexity would increase for a relatively simple task.
>>
>> It would seem to me that if you are looking for platform specific
>> actions to modify the stack(s) used in each platform build, then ideally
>> you would want a set of platform specific messages. i.e
>>
>> savingStandaloneForWindows
>> savingStandaloneForOSX
>> savingStandaloneForiOS
>> savingStandaloneForAndroid
>> savingStandaloneForHTML5
>> ...
>>
>> Or something like that. That way if you only meed to make a specific
>> scripted stack modification for Android, you only need to handle that
>> specific message.
>>
>>
>> On 11/15/2016 4:45 AM, Ali Lloyd 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
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>