Jacque wrote:
If you're just using red-dot breakpoints then it isn't as difficult to
remove them, you can just use the "remove all breakpoints" menu item.
I wonder if a case could be made for the IDE to also search and line in any
script that =
breakpoint
and either comment or delete
On 1/26/18 3:27 PM, Mark Wieder via use-livecode wrote:
On 01/26/2018 12:42 PM, J. Landman Gay via use-livecode wrote:
The deal is, if the standalone is anywhere near a running copy of the
IDE, remote debugging will kick in and stop the script (assuming the
"breakpoint" command works as expect
On 01/26/2018 12:42 PM, J. Landman Gay via use-livecode wrote:
The deal is, if the standalone is anywhere near a running copy of the
IDE, remote debugging will kick in and stop the script (assuming the
"breakpoint" command works as expected.) To avoid that, you'd need to
either quit LC, or res
On 1/26/18 1:11 PM, Mark Wieder via use-livecode wrote:
On 01/23/2018 01:15 PM, J. Landman Gay via use-livecode wrote:
On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:
@JLG I thought with "breaktpoint" you could debug SOS behaviors
I haven't actually tried that yet. It would be more d
On 01/23/2018 01:15 PM, J. Landman Gay via use-livecode wrote:
On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:
@JLG I thought with "breaktpoint" you could debug SOS behaviors
I haven't actually tried that yet. It would be more difficult to avoid
debugging when you just want to run th
I have not. I broke the remote debugger and haven't played with it in a
month or more. What I was thinking of doing was having a breakpoint
wrapper that only fires if I have a variable or property set, e.g. a global
called "debug", or having my "execute" debug method, that gives me an
answer box,
On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:
@JLG I thought with "breaktpoint" you could debug SOS behaviors
I haven't actually tried that yet. It would be more difficult to avoid
debugging when you just want to run the stack normally but would be
better than nothing. I suppose yo
@JLG I thought with "breaktpoint" you could debug SOS behaviors
On Tue, Jan 23, 2018 at 1:21 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On Tue, Jan 23, 2018 at 9:42 AM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On 2018-01-23
Navigator has used buttons on the second (never shown) card for a couple
years now. I'm currently testing a convert to SoS function in Navigator,
the first practical use of which will be to convert Navigator. I'm looking
forward to GitHub, and not having a directory listing like this hiding on
my c
On Tue, Jan 23, 2018 at 9:42 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote:
>
>> This actually raises another point (and I'm sure this is a discussion
>> that
>> happened without me several years ago, but as
There was a long and amusing discussion about what to call the object that
actually holds the behavior script. When behaviors were first implemented,
only buttons could be used as the container. In some cases it was necessary
to refer to the container button itself, for example, to get a propert
On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote:
This actually raises another point (and I'm sure this is a discussion
that
happened without me several years ago, but as long as we're here) is
there
a reason to use "this me" which seems terribly awkward, over "the
behavior
of me" whic
Geoff Canyon wrote:
> "the behavior of me" accomplishes the same thing as "this me"
> in a behavior script, and is far more clear besides.
Agreed, and there was a long thread about alternatives back when
"this me" was proposed, but it's been around so long now that I doubt
it's going away.
It isn't This Me that is portable (Mark indicated it shouldn't be used anywhere
but in a behavior script itself if I recall) but it is simple Me that is
portable. Me will always refer to the object USING a behavior (or not as the
case may be) and not the behavior itself.
Bob S
> On Jan 23, 2
I just checked, and yeah, this me is portable between object scripts and
behavior scripts, but it seems highly unlikely that the concept itself
would be portable. i.e. it's far more often the case that a reference to
me/this me from an object's script *should* be a reference to the control
itself,
This Me refers to the behavior object itself, not the object using the
behavior. That is so that scripts referring to Me can be ported to a behavior
without modification (I assume) and Me will still refer to the calling object.
I suppose they could have used Real Me or some such thing.
I have
On Tue, Jan 23, 2018 at 1:49 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 2018-01-22 21:20, Geoff Canyon via use-livecode wrote:
>
>> Is there any reason script-only stacks had to be implemented in the
>> engine?
>>
>
> Yes - otherwise direct stack references o
On 2018-01-22 21:20, Geoff Canyon via use-livecode wrote:
Is there any reason script-only stacks had to be implemented in the
engine?
Yes - otherwise direct stack references or 'stackfiles' indirected
references wouldn't work. You'd need a binary 'launcher' stack for each
script, which would
I don't think age of the QR means anything except someone was ahead of
their time. If the mothership suddenly says "aha" then we get "aha"
On Mon, Jan 22, 2018 at 6:30 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Yeah, the five-liner is intended only as a way of im
Yeah, the five-liner is intended only as a way of implementing script-only
stacks with behavior chaining in code rather than the engine (since that
doesn't seem forthcoming. It seem many people are doing something very like
this, at a basic level I'm just proposing that standardizing would be
usefu
I agree that having the ability to use stacks (script-only in particular)
for behaviors is nice -- it lets developers easily put all their code under
source control. But the implementation is flawed, as we've discussed,
because it doesn't support (native, transparent) chaining of behaviors, and
so
We are starting to get a bit afield, but as long as we are, the issues with
the layout editor bring us to the same place as the issues with the script
editor: Why exert so much effort on the editor instead of writing plugins
for third-party OSS editors, that have a much larger user base and
develo
Not barking up the wrong tree at all, with multi-stack apps very much in the
wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_) not
having and a RCS for the binary stacks themselves is a nuisance. But your 5
liner doesn't solve that either.
But how does creating a stack and s
On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Is there any reason script-only stacks had to be implemented in the engine?
>
It is nice that you can store the scripts for controls in a UI stack
alongside of the ui stack file. You just set
24 matches
Mail list logo
