Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

How about the adequately lengthy ID? 

Bob


On Dec 27, 2011, at 2:49 PM, J. Landman Gay wrote:

> On 12/27/11 3:00 PM, Mark Wieder wrote:
>> Todd Geist  writes:
>> 
>>> On a side note. I can't set a Behavior to any other then the Short
>>> Reference.  I set it with a Long ID including the path.  But it is
>>> immediately converted to the short "button id 1020 of stack behaviors" form
>> 
>> That's known as the "rugged" id
> 
> I think it should be called the "short long ID". We also have room to add a 
> "long short ID" if necessary.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

Ok, got it. NOW I know everything! I was just missing that little bit. ;-)

Bob


On Dec 27, 2011, at 12:57 PM, Richard Gaskin wrote:

> Bob Sneidar wrote:
> 
> > On Dec 27, 2011, at 12:28 PM, Todd Geist wrote:
> >> It starts as this
> >>
> >> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"
> >>
> >> it changes to this
> >>
> >> button id 1004 of stack "A"
> >
> > That is still the long ID.
> 
> Sort of.  A true long ID includes the file path, but behaviors use a special 
> form of that descriptor format with the short name of the stack, for 
> portability as Todd surmised.
> 
> This sort of "truncated long ID" is useful in other areas as well, and FWIW I 
> submitted a request to have a "truncated" keyword added to return that value 
> for object references:
> 
> 
> It's not too hard to write a function to do this, but since apparently the 
> engine already does this for behaviors it would be handy to have it 
> accessible to us in scripts.
> 
> --
> Richard Gaskin
> Fourth World
> LiveCode training and consulting: http://www.fourthworld.com
> Webzine for LiveCode developers: http://www.LiveCodeJournal.com
> LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[J. Landman Gay]

On 12/27/11 3:00 PM, Mark Wieder wrote:

Todd Geist  writes:


On a side note. I can't set a Behavior to any other then the Short
Reference.  I set it with a Long ID including the path.  But it is
immediately converted to the short "button id 1020 of stack behaviors" form


That's known as the "rugged" id


I think it should be called the "short long ID". We also have room to 
add a "long short ID" if necessary.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Pete]

Hi Todd,
It's my understanding that the start using command makes the handlers in
the stack script of the main stack available to your application.  Nothing
else, including behavior button scripts, are made available by issuing a
start using command.  No doubt someone will correct me if I'm wrong!

This is very similar to the situation that I have where I have my behavior
buttons on a card in a substack of the stack I name in my start using
command.  I remember tearing my hair out trying to figure out how to
activate the behaviors and I honestly don't remember all the things I
tried.  All I know is that using the Stack Files tab of the main stack's
Inspector palette to make a reference to the short name of my behavior
substack resolve to the full path of it's main stack fixed the problem for
me.  I guess LC opens the stacks named in the stack files list when it
first starts up, although you still have to use the start using command to
make the main stack script handlers available to your application.

I agree with Richard that the ability to issue a command that will resolve
behaviors at any time would be great, kinda like inserting/removing front
scripts.  I voted for his enhancement request.

On Tue, Dec 27, 2011 at 2:19 PM, Todd Geist wrote:

> On Tue, Dec 27, 2011 at 1:59 PM, Richard Gaskin
> wrote:
> >
> > If you find the script is in play under such circumstances, I'd like to
> > learn how you did it.
> >
> > I've been wanting a way to resolve behaviors at arbitrary execution
> points
> > rather than relying on stack opening, and have made this request for a
> new
> > "resolve behaviors" command to do that:
> >  http://quality.runrev.com/show_bug.cgi?id=8993>
> > >
> >
>
> Well I am not sure if I have what you are looking for. But I can tell you
> that I have behaviors in a sort of half linked state.  They do not work BUT
> in the IDE if you control click on a such button with a broken behavior and
> select "Send Message" you will see the Handlers in the Behavior script.  If
> you try to to send the message, it fails.
>
> My Behaviors are on the second card of a Library Stack. That was loaded
> into memory using "start using". It was not opened before the "start
> using".  These Behaviors are loaded AFTER the stack that uses them. And it
> is this stack that has the broken behaviors.  This makes sense since I am
> loading the behaviors too late.  But the behaviors are in memory they are
> just not correctly linked to their child buttons any more.
>
> in my case I can fix these quite easily because all the broken buttons are
> on one card. I am using them for code only.  I simply loop through the
> controls on the card and set the behavior of each control to itself.
>
> *On* ResetBeahviors
>
>   *repeat* with i = 1 to the number of controls of me
>
>  *put* the long id of control i of me into tControl
>
>  *put* word 1 of the name of tControl into tType
>
>  *if* tType = "button" *then*
>
> *set* the behavior of tControl to the behavior of tControl
>
>  *end* *if*
>
>   *end* *repeat*
>
> *end* ResetBeahviors
>
>
> Hope that helps
>
> Todd
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

On Tue, Dec 27, 2011 at 1:59 PM, Richard Gaskin
wrote:
>
> If you find the script is in play under such circumstances, I'd like to
> learn how you did it.
>
> I've been wanting a way to resolve behaviors at arbitrary execution points
> rather than relying on stack opening, and have made this request for a new
> "resolve behaviors" command to do that:
> 
> >
>

Well I am not sure if I have what you are looking for. But I can tell you
that I have behaviors in a sort of half linked state.  They do not work BUT
in the IDE if you control click on a such button with a broken behavior and
select "Send Message" you will see the Handlers in the Behavior script.  If
you try to to send the message, it fails.

My Behaviors are on the second card of a Library Stack. That was loaded
into memory using "start using". It was not opened before the "start
using".  These Behaviors are loaded AFTER the stack that uses them. And it
is this stack that has the broken behaviors.  This makes sense since I am
loading the behaviors too late.  But the behaviors are in memory they are
just not correctly linked to their child buttons any more.

in my case I can fix these quite easily because all the broken buttons are
on one card. I am using them for code only.  I simply loop through the
controls on the card and set the behavior of each control to itself.

*On* ResetBeahviors

   *repeat* with i = 1 to the number of controls of me

  *put* the long id of control i of me into tControl

  *put* word 1 of the name of tControl into tType

  *if* tType = "button" *then*

 *set* the behavior of tControl to the behavior of tControl

  *end* *if*

   *end* *repeat*

*end* ResetBeahviors


Hope that helps

Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Richard Gaskin]

Todd Geist wrote:


However I can reliably cause them stop working, by loading the object that
use Behaviors before the Behaviors themselves.


Unless something changed/broke, any behavior assignment which refers to 
a behavior button not already in memory at the time the object which 
refers to its is first opened will not have the behavior resolved, and 
that behavior script will not be present in the message path.


Accordingly, setting any breakpoints in the behavior script will not 
trigger, as the script isn't in play.


If you find the script is in play under such circumstances, I'd like to 
learn how you did it.


I've been wanting a way to resolve behaviors at arbitrary execution 
points rather than relying on stack opening, and have made this request 
for a new "resolve behaviors" command to do that:



If you have a means of doing this with the engine as it is I definitely 
want to learn the secret.


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

Hi Mark,

On Tue, Dec 27, 2011 at 1:12 PM, Mark Wieder  wrote:
>
> Just for the record, breakpoints work fine in behavior scripts.


Yes, normally they work just fine.

However I can reliably cause them stop working, by loading the object that
use Behaviors before the Behaviors themselves.  When this happens the link
is sort of there as I described in my Original Post. You can't send
reliably send messages, but you can see the behavior messages in some parts
of the IDE.

Another side effect of this half linked state is that you can't set break
points in the Behavior Scripts.

At least this is what I see in 5.0.2

Thanks

Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Mark Wieder]

Todd Geist  writes:

> And I can't set break points in the Behavior scripts.

Just for the record, breakpoints work fine in behavior scripts.

-- 
 Mark Wieder




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Pete]

That's interesting, I haven't come across that before, but I think you are
on 5.0 so maybe they changed (or broke) something in that release.  In
those circumstances, it seems worth at least setting the stackfiles to
"A,/Users/todd/Desktop/A.livecode" and see if that fixes the problem.

On Tue, Dec 27, 2011 at 12:38 PM, Todd Geist wrote:

> Yeah sorry see my other message
>
> It starts as this
>
> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"
>
>
> it changes to this
>
> button id 1004 of stack "A"
>
>
> Todd
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Pete]

I hate using the long ID.  The development and live versions of my
behaviors are in two different stack files so dev work doesn't cause
problems with live work.  If I used the long form of the behavior
references, I'd have to go and change all of them every time I put a new
version of an application into the live environment.  Using the stackFiles
to fully dereference the behavior stack name means I only have to change
the stackfiles setting to point to a different behavior stack file and I'm
done.

On Tue, Dec 27, 2011 at 12:05 PM, Bob Sneidar  wrote:

> Good point. The proper syntax *should* be
> set the behavior of  to the long id of button .
> If the behavior script button is located on the first card of the stack the
> object is in, then you can use shorter versions, but why risk it? In your
> case, since the behavior is in a library, use the long ID.
>
> Bob
>
>
> On Dec 27, 2011, at 11:23 AM, Pete wrote:
>
> > OK, not exactly the same issue I had but stackfiles might still help.  If
> > your behaviors don't use a fully qualified stack file name (eg button id
> > 1020 of stack "Behaviors"), a stackfiles entry naming Behaviors and its
> > fully qualified stackfile path enables LC to resolve the behavior
> > references.  Not sure if that's your situation but maybe that will help.
> > Pete
> >
> > On Tue, Dec 27, 2011 at 10:47 AM, Todd Geist  >wrote:
> >
> >> They are in the Library Stack itself not a substack.
> >>
> >> So you essentially injected the Library stack into the Main stack?
> >>
> >> On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:
> >>
> >>> Are the behavior buttons in the actual library stack or in a substack
> of
> >>> the library stack?  I've run into a similar problem before and ending
> >>> setting thew stackFiles property of the app's main stack to name the
> >>> behavior stack.
> >>> Pete
> >>>
> >>
> >> Todd
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >
> >
> > --
> > Pete
> > Molly's Revenge 
> > ___
> > use-livecode mailing list
> > use-livecode@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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Mark Wieder]

Todd Geist  writes:

> On a side note. I can't set a Behavior to any other then the Short
> Reference.  I set it with a Long ID including the path.  But it is
> immediately converted to the short "button id 1020 of stack behaviors" form

That's known as the "rugged" id - it's got everything in the long id except for
the file path to the stack. It's what behaviors are defined by. And it should be
unique because LC will barf if you have two stacks by the same name in memory.

-- 
 Mark Wieder


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Richard Gaskin]

Bob Sneidar wrote:

> On Dec 27, 2011, at 12:28 PM, Todd Geist wrote:
>> It starts as this
>>
>> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"
>>
>> it changes to this
>>
>> button id 1004 of stack "A"
>
> That is still the long ID.

Sort of.  A true long ID includes the file path, but behaviors use a 
special form of that descriptor format with the short name of the stack, 
for portability as Todd surmised.


This sort of "truncated long ID" is useful in other areas as well, and 
FWIW I submitted a request to have a "truncated" keyword added to return 
that value for object references:



It's not too hard to write a function to do this, but since apparently 
the engine already does this for behaviors it would be handy to have it 
accessible to us in scripts.


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 LiveCode Journal blog: http://LiveCodejournal.com/blog.irv

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

That is still the long ID. 

Bob


On Dec 27, 2011, at 12:28 PM, Todd Geist wrote:

> whoops
> 
> That didn't paste right
> 
> It starts as this
> 
> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"
> 
> 
> it changes to this
> 
> button id 1004 of stack "A"
> 
> 
> Todd
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

Yeah sorry see my other message

It starts as this

button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"


it changes to this

button id 1004 of stack "A"


Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

mmm that IS the long ID. The short id would just be a number. But you *can* use 
the short name, and it wouldn't surprise me if Livecode then transformed that 
into the long ID. I wasn't aware of that. 

Bob


On Dec 27, 2011, at 12:19 PM, Todd Geist wrote:

> If Set this
> 
> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"
> 
> LiveCode immediately changes it to
> 
> button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

whoops

That didn't paste right

It starts as this

button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"


it changes to this

button id 1004 of stack "A"


Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

I am using the long ID when I set it.  But LiveCode immediately converts it
to the shorter version It is not my doing.

If Set this

button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"

LiveCode immediately changes it to

button id 1004 of card id 1002 of stack "/Users/todd/Desktop/A.livecode"

This is a good I think. I am pretty sure you wouldn't want to include the
full path to a stack in a behavior

Todd


On Tue, Dec 27, 2011 at 12:05 PM, Bob Sneidar  wrote:

> Good point. The proper syntax *should* be
> set the behavior of  to the long id of button .
> If the behavior script button is located on the first card of the stack the
> object is in, then you can use shorter versions, but why risk it? In your
> case, since the behavior is in a library, use the long ID.
>
> Bob
>
>
> On Dec 27, 2011, at 11:23 AM, Pete wrote:
>
> > OK, not exactly the same issue I had but stackfiles might still help.  If
> > your behaviors don't use a fully qualified stack file name (eg button id
> > 1020 of stack "Behaviors"), a stackfiles entry naming Behaviors and its
> > fully qualified stackfile path enables LC to resolve the behavior
> > references.  Not sure if that's your situation but maybe that will help.
> > Pete
> >
> > On Tue, Dec 27, 2011 at 10:47 AM, Todd Geist  >wrote:
> >
> >> They are in the Library Stack itself not a substack.
> >>
> >> So you essentially injected the Library stack into the Main stack?
> >>
> >> On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:
> >>
> >>> Are the behavior buttons in the actual library stack or in a substack
> of
> >>> the library stack?  I've run into a similar problem before and ending
> >>> setting thew stackFiles property of the app's main stack to name the
> >>> behavior stack.
> >>> Pete
> >>>
> >>
> >> Todd
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >>
> >>
> >
> >
> > --
> > Pete
> > Molly's Revenge 
> > ___
> > use-livecode mailing list
> > use-livecode@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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Todd Geist


(805) 419-9382
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

Thanks Pete, but that doesn't help.

On a side note. I can't set a Behavior to any other then the Short
Reference.  I set it with a Long ID including the path.  But it is
immediately converted to the short "button id 1020 of stack behaviors" form

Todd

On Tue, Dec 27, 2011 at 11:23 AM, Pete  wrote:

> OK, not exactly the same issue I had but stackfiles might still help.  If
> your behaviors don't use a fully qualified stack file name (eg button id
> 1020 of stack "Behaviors"), a stackfiles entry naming Behaviors and its
> fully qualified stackfile path enables LC to resolve the behavior
> references.  Not sure if that's your situation but maybe that will help.
> Pete
>
> On Tue, Dec 27, 2011 at 10:47 AM, Todd Geist  >wrote:
>
> > They are in the Library Stack itself not a substack.
> >
> > So you essentially injected the Library stack into the Main stack?
> >
> > On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:
> >
> > > Are the behavior buttons in the actual library stack or in a substack
> of
> > > the library stack?  I've run into a similar problem before and ending
> > > setting thew stackFiles property of the app's main stack to name the
> > > behavior stack.
> > > Pete
> > >
> >
> > Todd
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
>
>
> --
> Pete
> Molly's Revenge 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Todd Geist


(805) 419-9382
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

Good point. The proper syntax *should* be
set the behavior of  to the long id of button . If 
the behavior script button is located on the first card of the stack the object 
is in, then you can use shorter versions, but why risk it? In your case, since 
the behavior is in a library, use the long ID. 

Bob


On Dec 27, 2011, at 11:23 AM, Pete wrote:

> OK, not exactly the same issue I had but stackfiles might still help.  If
> your behaviors don't use a fully qualified stack file name (eg button id
> 1020 of stack "Behaviors"), a stackfiles entry naming Behaviors and its
> fully qualified stackfile path enables LC to resolve the behavior
> references.  Not sure if that's your situation but maybe that will help.
> Pete
> 
> On Tue, Dec 27, 2011 at 10:47 AM, Todd Geist wrote:
> 
>> They are in the Library Stack itself not a substack.
>> 
>> So you essentially injected the Library stack into the Main stack?
>> 
>> On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:
>> 
>>> Are the behavior buttons in the actual library stack or in a substack of
>>> the library stack?  I've run into a similar problem before and ending
>>> setting thew stackFiles property of the app's main stack to name the
>>> behavior stack.
>>> Pete
>>> 
>> 
>> Todd
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
> 
> 
> -- 
> Pete
> Molly's Revenge 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Pete]

OK, not exactly the same issue I had but stackfiles might still help.  If
your behaviors don't use a fully qualified stack file name (eg button id
1020 of stack "Behaviors"), a stackfiles entry naming Behaviors and its
fully qualified stackfile path enables LC to resolve the behavior
references.  Not sure if that's your situation but maybe that will help.
Pete

On Tue, Dec 27, 2011 at 10:47 AM, Todd Geist wrote:

> They are in the Library Stack itself not a substack.
>
> So you essentially injected the Library stack into the Main stack?
>
> On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:
>
> > Are the behavior buttons in the actual library stack or in a substack of
> > the library stack?  I've run into a similar problem before and ending
> > setting thew stackFiles property of the app's main stack to name the
> > behavior stack.
> > Pete
> >
>
> Todd
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

They are in the Library Stack itself not a substack.

So you essentially injected the Library stack into the Main stack?

On Tue, Dec 27, 2011 at 10:39 AM, Pete  wrote:

> Are the behavior buttons in the actual library stack or in a substack of
> the library stack?  I've run into a similar problem before and ending
> setting thew stackFiles property of the app's main stack to name the
> behavior stack.
> Pete
>

Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

I am using 5.0.2.  But I am not sure if thats the issue.  I looked for the
thread you referenced but I can't find it, any hints on the keywords?

Thanks

Todd

On Tue, Dec 27, 2011 at 10:36 AM, Bob Sneidar  wrote:

> Ah, IC. Are you using 5.02? There is the thread about things not loading
> in the order you would expect with version 5.02. Might it have something to
> do with that?




-- 
Todd Geist


(805) 419-9382
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Pete]

Are the behavior buttons in the actual library stack or in a substack of
the library stack?  I've run into a similar problem before and ending
setting thew stackFiles property of the app's main stack to name the
behavior stack.
Pete

On Tue, Dec 27, 2011 at 10:23 AM, Todd Geist wrote:

> On Tue, Dec 27, 2011 at 10:14 AM, Bob Sneidar  wrote:
>
> > Where are the behavior buttons located? They have to be in the open stack
> > or *AN* open stack. I may be mistaken about this, but I think I am not. I
> > have a behavior button on the first card of an app stack, and all my
> > behaviors work fine there. They should also work if they are on the first
> > card of any stack you start using. Someone who knows more should correct
> me
> > if I am wrong.
> >
>
> The behaviors are in a library stack.  That stack was being loaded by the
> Main stack, in a PreOpenCard handler. the Main stack was also using the
> behaviors.  They are two separate stacks.
>
> So the Main stack loads into memory, then On PreOpenCard it loads the
> Library stack that has the behaviors.  This is the problem.  If the library
> stack is loaded first into memory, everything works.  So I may need a
> launcher file that Loads the Libraries first THEN the main stack.
>
> Todd
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>


-- 
Pete
Molly's Revenge 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

Ah, IC. Are you using 5.02? There is the thread about things not loading in the 
order you would expect with version 5.02. Might it have something to do with 
that?

Bob


On Dec 27, 2011, at 10:23 AM, Todd Geist wrote:

> On Tue, Dec 27, 2011 at 10:14 AM, Bob Sneidar  wrote:
> 
>> Where are the behavior buttons located? They have to be in the open stack
>> or *AN* open stack. I may be mistaken about this, but I think I am not. I
>> have a behavior button on the first card of an app stack, and all my
>> behaviors work fine there. They should also work if they are on the first
>> card of any stack you start using. Someone who knows more should correct me
>> if I am wrong.
>> 
> 
> The behaviors are in a library stack.  That stack was being loaded by the
> Main stack, in a PreOpenCard handler. the Main stack was also using the
> behaviors.  They are two separate stacks.
> 
> So the Main stack loads into memory, then On PreOpenCard it loads the
> Library stack that has the behaviors.  This is the problem.  If the library
> stack is loaded first into memory, everything works.  So I may need a
> launcher file that Loads the Libraries first THEN the main stack.
> 
> Todd
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Todd Geist]

On Tue, Dec 27, 2011 at 10:14 AM, Bob Sneidar  wrote:

> Where are the behavior buttons located? They have to be in the open stack
> or *AN* open stack. I may be mistaken about this, but I think I am not. I
> have a behavior button on the first card of an app stack, and all my
> behaviors work fine there. They should also work if they are on the first
> card of any stack you start using. Someone who knows more should correct me
> if I am wrong.
>

The behaviors are in a library stack.  That stack was being loaded by the
Main stack, in a PreOpenCard handler. the Main stack was also using the
behaviors.  They are two separate stacks.

So the Main stack loads into memory, then On PreOpenCard it loads the
Library stack that has the behaviors.  This is the problem.  If the library
stack is loaded first into memory, everything works.  So I may need a
launcher file that Loads the Libraries first THEN the main stack.

Todd
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Case Study: Behaviors Failing - Can't set break points

[Bob Sneidar]

Where are the behavior buttons located? They have to be in the open stack or 
*AN* open stack. I may be mistaken about this, but I think I am not. I have a 
behavior button on the first card of an app stack, and all my behaviors work 
fine there. They should also work if they are on the first card of any stack 
you start using. Someone who knows more should correct me if I am wrong. 

Bob


On Dec 27, 2011, at 9:36 AM, Todd Geist wrote:

> Hello,
> 
> I just ran into this issue and I thought I would share it. I thought I was
> loading my Behavior's into memory before using them but I wasn't.  Here is
> what it looked like when it was failing.
> 
> I have some buttons that have behaviors set on them.  When you
> control-click on them and look at Send Message, the commands that are
> associated with the behavior are there. So, I thought, the button is
> clearly linked to it's behavior. However using Dispatch to send the message
> results in "unhandled". It was not seeing the behavior's handlers.
> 
> If I use the Send form I can see that the message is sent to the Button,
> but is not picked up by the Behavior, just the Button. Even if there is no
> handler for the message in the button. I can tell this by stepping through
> with the debugger.  The debugger goes to the button's Script ( not the
> behavior's script ) even though the script is empty.  It never makes it on
> to the behavior.
> 
> I also noticed that I couldn't set Break Points in the behavior scripts in
> the debugger when this condition happened.  They just didn't work.
> 
> In all cases, I can it by simply resetting the behavior to itself, like so:
> 
> *set *the behavior of tControl to the behavior of tControl
> 
> 
> So whats the deal? The button appears to be linked to the behavior? But I
> can't send it messages?  And I can't set break points in the Behavior
> scripts.
> 
> Well the problem is that the behaviors are not in memory when the buttons
> that use them are placed into memory.  I thought that they were because I
> was loading the stack containing the Behaviors as part of the PreOpenCard
> in my first stack.  So the Behaviors were in a second stack.  And they were
> being referenced by the first stack.
> 
> I think the docs point this out, but I was confused by the apparent
> linking, and the fact that I thought loading on PreOpenCard or PreOpenStack
> would be enough.  But its not.
> 
> I am including behaviors in a Library stack, instead of embedding them into
> a the stacks that use them. These are pure code Behaviors, no UI.  And they
> are part of the larger feature set provided by the library.  I wanted to be
> able to keep the library and it's behavior's separate. So either I will
> have to build a launcher file that just loads the library first or build in
> re-linking, which may not be a bad thing anyway.
> 
> ???
> 
> Todd
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode