Hah! I was wondering if anybody would get that.
> On Jun 9, 2016, at 6:53 PM, Dar Scott wrote:
>
> Yeah, I started out in FORTRAN a half century ago, and I have habits from
> that.
>
>> On Jun 9, 2016, at 7:42 PM, Jerry Jensen wrote:
>>
>> Heck, I still use i,j,k,l,m,n variables for intege
Yeah, I started out in FORTRAN a half century ago, and I have habits from that.
> On Jun 9, 2016, at 7:42 PM, Jerry Jensen wrote:
>
>
>> On Jun 9, 2016, at 6:31 PM, Mark Wieder wrote:
>>
>> On 06/09/2016 05:11 PM, Jerry Jensen wrote:
>>> True, true. in that example the “;” separates the de
> On Jun 9, 2016, at 6:31 PM, Mark Wieder wrote:
>
> On 06/09/2016 05:11 PM, Jerry Jensen wrote:
>> True, true. in that example the “;” separates the declaration command from
>> the assignment command. My mistake.
>>
>> However, here is an example that does the assignment right in the
>> decl
On 06/09/2016 05:11 PM, Jerry Jensen wrote:
True, true. in that example the “;” separates the declaration command from the
assignment command. My mistake.
However, here is an example that does the assignment right in the declaration
command, on the fly:
It seems to work (!). Honestly, I half e
True, true. in that example the “;” separates the declaration command from the
assignment command. My mistake.
However, here is an example that does the assignment right in the declaration
command, on the fly:
It seems to work (!). Honestly, I half expected it to fail on the first do.
on mouseU
On 06/08/2016 07:40 PM, Jerry Jensen wrote:
The dictionary claims that it is legal syntax (in 7 and 8). The example therein
shows that handler locals can be declared and assigned values at runtime using
a do in a loop. I would never have thought of that!
If you're referring to the dictionary
The dictionary claims that it is legal syntax (in 7 and 8). The example therein
shows that handler locals can be declared and assigned values at runtime using
a do in a loop. I would never have thought of that!
.Jerry
> On Jun 8, 2016, at 7:27 PM, Mark Wieder wrote:
>
> On 06/08/2016 05:50 PM,
On 06/08/2016 05:50 PM, Dar Scott wrote:
I'm curious about this, too.
I often assign values for script variables.
I'm used to doing that as well in most other environments.
Maybe it's just my faulty memory, but I think I remember discussions
here about not relying on assigning values to local
I'm curious about this, too.
I often assign values for script variables.
> On Jun 8, 2016, at 6:37 PM, Jerry Jensen wrote:
>
>
>> On Jun 8, 2016, at 4:20 PM, Mark Wieder wrote:
>>
>> I thought assigning values in a variable declaration was discouraged.
>
> I probably missed that memo,
> On 9 Jun 2016, at 9:20 AM, Mark Wieder wrote:
>
> 1: yes, but that rather defeats the purpose of having a separate routine
> for "startup", doesn't it?
Well the original request was for a startup handler to be called on first run
of a stack in the IDE so it does that.
>
> 2. I thought assig
> On Jun 8, 2016, at 4:20 PM, Mark Wieder wrote:
>
> I thought assigning values in a variable declaration was discouraged.
I probably missed that memo, I haven’t been keeping up as much as I should.
I’m not in the habit of doing that except with constants, but should I avoid
letting it become
Monte Goulding writes:
>
> Or:
>
> local sFIrstRun = "true"
>
> on preOpenStack
> if the owner of the target is me then
> if the environment is "development" and sFIrstRun then
> startup
> end if
> put false into sFIrstRun
> end if
> end preOpenStac
So, yes, I know there are a zillion work around. Boolean flags being the
most classic method. I already has such a work-around in place.
That said, it seems the consensus - so far - is that 'startup' only
executing in the Standalone is a "feature" that people have come to use
and expect, so I resp
Or:
local sFIrstRun = "true"
on preOpenStack
if the owner of the target is me then
if the environment is "development" and sFIrstRun then
startup
end if
put false into sFIrstRun
end if
end preOpenStack
Sent from my iPhone
> On 9 Jun 2016, at 6:40 AM,
Paul Dupuis writes:
>
> In LiveCode 6.7.11 and 8.1.0rc1 the startup message is send to your main
> stack when the mainstack is built as a standalone. However, if you open
> your stack in the IDE, the startup message is never received
As mentioned, this is by design, and it's quite a useful feat
Paul.
This was the way it worked in HC, but is different in LC.
Craig Newman
-Original Message-
From: Monte Goulding
To: How to use LiveCode
Sent: Wed, Jun 8, 2016 4:16 pm
Subject: Re: The 'startup' message not working in IDE
Hi Paul
This is as intended. Startup g
One of the issues is lots of people over the years have put code in there they
specifically don't want running in the IDE. I should have said standalone or
home stack or stack passed go the open source standalone engine on the command
line. I wonder if instead it would be feasible to pass a firs
I like the way it works now. I usually have a startup handler in the first card
of an app which gets things going, loads libraries etc. When I want to test the
app in the IDE, I just execute
send "startup" to cd "startcard" of stack "myinitialstack"
from the message box. That way the test run
On 6/8/2016 4:14 PM, Monte Goulding wrote:
> This is as intended. Startup goes to the first stack the engine runs not
> other stacks that are opened. Use preOpenStack for that.
Yes, but should the IDE count as the "first stack" opened? I would argue
that it should not. The first stack opened shou
Hi Paul
This is as intended. Startup goes to the first stack the engine runs not other
stacks that are opened. Use preOpenStack for that.
Cheers
Monte
Sent from my iPhone
> On 9 Jun 2016, at 6:09 AM, Paul Dupuis wrote:
>
> In LiveCode 6.7.11 and 8.1.0rc1 the startup message is send to your
In LiveCode 6.7.11 and 8.1.0rc1 the startup message is send to your main
stack when the mainstack is built as a standalone. However, if you open
your stack in the IDE, the startup message is never received
You can test this by making a new stack with the following script in the
stack script:
on st
21 matches
Mail list logo
