Mysteries of Me

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Mysteries of Me

Pi Digital via use-livecode
I thought I had a grip on "me"

But in a script that is assigned to a stack, one assumes that "me"
refers to stack itself.
But the auto-suggestion on the SE popup menu generates an error on the
following line:
*
on openstack
   put url ("binfile:" & path_Modules()& "listen/collection.json") into
tContainer
   put JSONToArray(tContainer) into sCollectionA  
   
   # must have net connection, otherwise take to My Audio
   if not connectivity_PingServer() then
      dialog_CustomMsg "No internet connection? Going to off-line library."
  [ERROR:}    go card [on tab on auto-suggestion] "listen-my-audio" of me
   end if
end openstack

# I have to use:
*
**on openstack
   put url ("binfile:" & path_Modules()& "listen/collection.json") into
tContainer
   put JSONToArray(tContainer) into sCollectionA  
   
   # must have net connection, otherwise take to My Audio
   if not ******connectivity_PingServer()** then
      dialog_CustomMsg "No internet connection? Going to off-line library."
      go to card "listen-my-audio" of this stack
   end if
end openstack

#Then the SE will compile the script*
# Why is "me" generating an error?
# It should not be a suggestion if it is.

Dictionary says:

*"The *me* keyword is a reference to the object whosescript contains the
current handler. If *me* is executed in behavior script, then *me*
refers to the object that is executing the behavior script."

on openStack ... "me" ... one would think, refer to cards in the stack?

Could it be that the function

 **connectivity_PingServer()

is called from a back script -- which has no binary "cards" such**

BR

 


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
the first version said "go card" not "go to card" :)

On Mon, Oct 29, 2018 at 11:14 AM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

> I thought I had a grip on "me"
>
> But in a script that is assigned to a stack, one assumes that "me"
> refers to stack itself.
> But the auto-suggestion on the SE popup menu generates an error on the
> following line:
> *
> on openstack
>    put url ("binfile:" & path_Modules()& "listen/collection.json") into
> tContainer
>    put JSONToArray(tContainer) into sCollectionA
>
>    # must have net connection, otherwise take to My Audio
>    if not connectivity_PingServer() then
>       dialog_CustomMsg "No internet connection? Going to off-line library."
>   [ERROR:}    go card [on tab on auto-suggestion] "listen-my-audio" of me
>    end if
> end openstack
>
> # I have to use:
> *
> **on openstack
>    put url ("binfile:" & path_Modules()& "listen/collection.json") into
> tContainer
>    put JSONToArray(tContainer) into sCollectionA
>
>    # must have net connection, otherwise take to My Audio
>    if not ******connectivity_PingServer()** then
>       dialog_CustomMsg "No internet connection? Going to off-line library."
>       go to card "listen-my-audio" of this stack
>    end if
> end openstack
>
> #Then the SE will compile the script*
> # Why is "me" generating an error?
> # It should not be a suggestion if it is.
>
> Dictionary says:
>
> *"The *me* keyword is a reference to the object whosescript contains the
> current handler. If *me* is executed in behavior script, then *me*
> refers to the object that is executing the behavior script."
>
> on openStack ... "me" ... one would think, refer to cards in the stack?
>
> Could it be that the function
>
>  **connectivity_PingServer()
>
> is called from a back script -- which has no binary "cards" such**
>
> BR
>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
Me always refers to the object the script belongs to. It doesn't matter which handler it is. A script running in a behavior is like running an instance of the target object (the object with the behavior set). This allows for multiple objects with the same behavior (think datagrids calling get the dgData in other dataGrids and you will immediately see why this would be necessary). This me refers to the actual behavior object, NOT the "instance object" as it were.

As far as a backscript, are you saying you have a backscript object with a behavior assigned to it??

Bob S


> On Oct 29, 2018, at 08:14 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
> I thought I had a grip on "me"


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
@tom  go card and go to card same thing.

@ bob

That's what I understand (as you have described it)

-- The behavior is set in the properties of a stack.
-- the SE suggestions "knows" this and on typing
      go card...[List of cards in current stack appears... choose one)

# you get:

go card "my-audio-library" of me  #as we would expect

# but it gives an error; will not compile. You have to be explicit:

go card "my-audio-library" of this stack

# then it compiles

-- re: backscript

function isThisTrue() then
    go card "my-audio-library" of me  # as per SE suggestions
   # generates an error
end isThisTrue

# isThisTrue , is part of a back script. It won't compile
# I wondered it that was causing a reference change
# because this works

function isThisTrue() then
    go card "my-audio-library" of this stack
end isThisTrue
 




On 10/29/18 11:59 AM, Bob Sneidar via use-livecode wrote:
> Me always refers to the object the script belongs to. It doesn't matter which handler it is. A script running in a behavior is like running an instance of the target object (the object with the behavior set). This allows for multiple objects with the same behavior (think datagrids calling get the dgData in other dataGrids and you will immediately see why this would be necessary). This me refers to the actual behavior object, NOT the "instance object" as it were.
>
> As far as a backscript, are you saying you have a backscript object with a behavior assigned to it??
>
> Bob S


--
Svasti Astu, Be Well!
Brahmanathaswami

Get the SivaSiva app, it's free:
https://www.himalayanacademy.com/apps/sivasiva

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
oh...didn't know that syntax would work ....first thing that jumped out at
me .... thought maybe it was as simple as that. :)

On Mon, Oct 29, 2018 at 8:15 PM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

> @tom  go card and go to card same thing.
>
> @ bob
>
> That's what I understand (as you have described it)
>
> -- The behavior is set in the properties of a stack.
> -- the SE suggestions "knows" this and on typing
>       go card...[List of cards in current stack appears... choose one)
>
> # you get:
>
> go card "my-audio-library" of me  #as we would expect
>
> # but it gives an error; will not compile. You have to be explicit:
>
> go card "my-audio-library" of this stack
>
> # then it compiles
>
> -- re: backscript
>
> function isThisTrue() then
>     go card "my-audio-library" of me  # as per SE suggestions
>    # generates an error
> end isThisTrue
>
> # isThisTrue , is part of a back script. It won't compile
> # I wondered it that was causing a reference change
> # because this works
>
> function isThisTrue() then
>     go card "my-audio-library" of this stack
> end isThisTrue
>
>
>
>
>
> On 10/29/18 11:59 AM, Bob Sneidar via use-livecode wrote:
> > Me always refers to the object the script belongs to. It doesn't matter
> which handler it is. A script running in a behavior is like running an
> instance of the target object (the object with the behavior set). This
> allows for multiple objects with the same behavior (think datagrids calling
> get the dgData in other dataGrids and you will immediately see why this
> would be necessary). This me refers to the actual behavior object, NOT the
> "instance object" as it were.
> >
> > As far as a backscript, are you saying you have a backscript object with
> a behavior assigned to it??
> >
> > Bob S
>
>
> --
> Svasti Astu, Be Well!
> Brahmanathaswami
>
> Get the SivaSiva app, it's free:
> https://www.himalayanacademy.com/apps/sivasiva
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
On 10/29/18 7:42 PM, Tom Glod via use-livecode wrote:
> oh...didn't know that syntax would work ....first thing that jumped out at
> me .... thought maybe it was as simple as that. :)


You learn as you go, with the plug in  TinyDictionary.

I refer to it all the time...

Best way to access the dictionary.

Thank Bernd Niggemann and James Hale!

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
Ah yes I've encountered this. What I do is I have 2 functions: getParentCard() and getParentStack(). pass the long id of any object on a card and they return the long id of the card, or the long filename of the stack respectively. Then you can use go tParentCard and that will compile. Your issue is in fact, why I wrote these functions! They are very simple as you can see:

function getParentCard pObjectID
   put offset("card id", pObjectID) into tStartChar
   put char tStartChar to -1 of pObjectID into tCardID
   return tCardID
end getParentCard

function getParentStack pObjectID
   put offset("stack ", pObjectID) into tStartChar
   put char tStartChar to -1 of pObjectID into tParentStack
   return tParentStack
end getParentStack

Bob S


> On Oct 29, 2018, at 17:15 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
> @tom  go card and go to card same thing.
>
> @ bob
>
> That's what I understand (as you have described it)
>
> -- The behavior is set in the properties of a stack.
> -- the SE suggestions "knows" this and on typing
>      go card...[List of cards in current stack appears... choose one)
>
> # you get:
>
> go card "my-audio-library" of me  #as we would expect
>
> # but it gives an error; will not compile. You have to be explicit:
>
> go card "my-audio-library" of this stack
>
> # then it compiles
>
> -- re: backscript
>
> function isThisTrue() then
>    go card "my-audio-library" of me  # as per SE suggestions
>   # generates an error
> end isThisTrue
>
> # isThisTrue , is part of a back script. It won't compile
> # I wondered it that was causing a reference change
> # because this works
>
> function isThisTrue() then
>    go card "my-audio-library" of this stack
> end isThisTrue


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
Hmm, is that a bug?  Should we report it? I think so.



On 10/30/18 5:54 AM, Bob Sneidar via use-livecode wrote:

> Ah yes I've encountered this. What I do is I have 2 functions: getParentCard() and getParentStack(). pass the long id of any object on a card and they return the long id of the card, or the long filename of the stack respectively. Then you can use go tParentCard and that will compile. Your issue is in fact, why I wrote these functions! They are very simple as you can see:
>
> function getParentCard pObjectID
>    put offset("card id", pObjectID) into tStartChar
>    put char tStartChar to -1 of pObjectID into tCardID
>    return tCardID
> end getParentCard
>
> function getParentStack pObjectID
>    put offset("stack ", pObjectID) into tStartChar
>    put char tStartChar to -1 of pObjectID into tParentStack
>    return tParentStack
> end getParentStack
>
> Bob S
>
>
>> On Oct 29, 2018, at 17:15 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>>
>> @tom  go card and go to card same thing.
>>
>> @ bob
>>
>> That's what I understand (as you have described it)
>>
>> -- The behavior is set in the properties of a stack.
>> -- the SE suggestions "knows" this and on typing
>>      go card...[List of cards in current stack appears... choose one)
>>
>> # you get:
>>
>> go card "my-audio-library" of me  #as we would expect
>>
>> # but it gives an error; will not compile. You have to be explicit:
>>
>> go card "my-audio-library" of this stack
>>
>> # then it compiles
>>
>> -- re: backscript
>>
>> function isThisTrue() then
>>    go card "my-audio-library" of me  # as per SE suggestions
>>   # generates an error
>> end isThisTrue
>>
>> # isThisTrue , is part of a back script. It won't compile
>> # I wondered it that was causing a reference change
>> # because this works
>>
>> function isThisTrue() then
>>    go card "my-audio-library" of this stack
>> end isThisTrue



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
It's not a bug, it's a limitation (probably the wrong word) of the parser. As has been talked about in the past, messing with the parser is one of the least desirable things the devs have to do, and from what I have gleaned, they avoid it if at all possible. The parser is really where all the LC magic is. Currently the spells are working quite nicely. You don't want to mess with the magic. :-)

Bob S


> On Oct 30, 2018, at 10:56 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
> Hmm, is that a bug?  Should we report it? I think so.
>
>
>
> On 10/30/18 5:54 AM, Bob Sneidar via use-livecode wrote:
>> Ah yes I've encountered this. What I do is I have 2 functions: getParentCard() and getParentStack(). pass the long id of any object on a card and they return the long id of the card, or the long filename of the stack respectively. Then you can use go tParentCard and that will compile. Your issue is in fact, why I wrote these functions! They are very simple as you can see:
>>
>> function getParentCard pObjectID
>>   put offset("card id", pObjectID) into tStartChar
>>   put char tStartChar to -1 of pObjectID into tCardID
>>   return tCardID
>> end getParentCard
>>
>> function getParentStack pObjectID
>>   put offset("stack ", pObjectID) into tStartChar
>>   put char tStartChar to -1 of pObjectID into tParentStack
>>   return tParentStack
>> end getParentStack
>>
>> Bob S
>>
>>
>>> On Oct 29, 2018, at 17:15 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>>>
>>> @tom  go card and go to card same thing.
>>>
>>> @ bob
>>>
>>> That's what I understand (as you have described it)
>>>
>>> -- The behavior is set in the properties of a stack.
>>> -- the SE suggestions "knows" this and on typing
>>>     go card...[List of cards in current stack appears... choose one)
>>>
>>> # you get:
>>>
>>> go card "my-audio-library" of me  #as we would expect
>>>
>>> # but it gives an error; will not compile. You have to be explicit:
>>>
>>> go card "my-audio-library" of this stack
>>>
>>> # then it compiles
>>>
>>> -- re: backscript
>>>
>>> function isThisTrue() then
>>>   go card "my-audio-library" of me  # as per SE suggestions
>>>  # generates an error
>>> end isThisTrue
>>>
>>> # isThisTrue , is part of a back script. It won't compile
>>> # I wondered it that was causing a reference change
>>> # because this works
>>>
>>> function isThisTrue() then
>>>   go card "my-audio-library" of this stack
>>> end isThisTrue
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
A guess: "me" resolves correctly for controls only. Stacks and cards are
not controls, so behaviors attached to those resolve to the behavior script
itself. Since there are no cards in a behavior script, it fails. Maybe.
--
Jacqueline Landman Gay | [hidden email]
HyperActive Software | http://www.hyperactivesw.com
On October 31, 2018 10:39:53 AM Bob Sneidar via use-livecode
<[hidden email]> wrote:

> It's not a bug, it's a limitation (probably the wrong word) of the parser.
> As has been talked about in the past, messing with the parser is one of the
> least desirable things the devs have to do, and from what I have gleaned,
> they avoid it if at all possible. The parser is really where all the LC
> magic is. Currently the spells are working quite nicely. You don't want to
> mess with the magic. :-)
>
> Bob S
>
>
>> On Oct 30, 2018, at 10:56 , Sannyasin Brahmanathaswami via use-livecode
>> <[hidden email]> wrote:
>>
>> Hmm, is that a bug?  Should we report it? I think so.
>>
>>
>>
>> On 10/30/18 5:54 AM, Bob Sneidar via use-livecode wrote:
>>> Ah yes I've encountered this. What I do is I have 2 functions:
>>> getParentCard() and getParentStack(). pass the long id of any object on a
>>> card and they return the long id of the card, or the long filename of the
>>> stack respectively. Then you can use go tParentCard and that will compile.
>>> Your issue is in fact, why I wrote these functions! They are very simple as
>>> you can see:
>>>
>>> function getParentCard pObjectID
>>>   put offset("card id", pObjectID) into tStartChar
>>>   put char tStartChar to -1 of pObjectID into tCardID
>>>   return tCardID
>>> end getParentCard
>>>
>>> function getParentStack pObjectID
>>>   put offset("stack ", pObjectID) into tStartChar
>>>   put char tStartChar to -1 of pObjectID into tParentStack
>>>   return tParentStack
>>> end getParentStack
>>>
>>> Bob S
>>>
>>>
>>>> On Oct 29, 2018, at 17:15 , Sannyasin Brahmanathaswami via use-livecode
>>>> <[hidden email]> wrote:
>>>>
>>>> @tom  go card and go to card same thing.
>>>>
>>>> @ bob
>>>>
>>>> That's what I understand (as you have described it)
>>>>
>>>> -- The behavior is set in the properties of a stack.
>>>> -- the SE suggestions "knows" this and on typing
>>>>     go card...[List of cards in current stack appears... choose one)
>>>>
>>>> # you get:
>>>>
>>>> go card "my-audio-library" of me  #as we would expect
>>>>
>>>> # but it gives an error; will not compile. You have to be explicit:
>>>>
>>>> go card "my-audio-library" of this stack
>>>>
>>>> # then it compiles
>>>>
>>>> -- re: backscript
>>>>
>>>> function isThisTrue() then
>>>>   go card "my-audio-library" of me  # as per SE suggestions
>>>>  # generates an error
>>>> end isThisTrue
>>>>
>>>> # isThisTrue , is part of a back script. It won't compile
>>>> # I wondered it that was causing a reference change
>>>> # because this works
>>>>
>>>> function isThisTrue() then
>>>>   go card "my-audio-library" of this stack
>>>> end isThisTrue
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
Me is resolving correctly for me in stack, card and behavior scripts attached to them. The issue I think was that you cannot seem to reference card <x> of me in a stack script handler. So I created handlers that return the parent card or stack of an object. The object can be the long id of a card even, when getting the parent stack, and that you can use in any reference so far as I know.

All it's doing is forcing the full card ID or stack name resolution so the parser doesn't need to use fuzzy logic.

Bob S


> On Oct 31, 2018, at 09:04 , J. Landman Gay via use-livecode <[hidden email]> wrote:
>
> A guess: "me" resolves correctly for controls only. Stacks and cards are not controls, so behaviors attached to those resolve to the behavior script itself. Since there are no cards in a behavior script, it fails. Maybe.
> --
> Jacqueline Landman Gay


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
Bob, that make sense. But why do need those handlers?
 
What not just use "of this stack"?

Obviously, I am oblivious to the number contexts where you require:

"...created handlers that return the parent card or stack of an object."

I am curious what they are?

BR

Bob Sneidar via use-livecode wrote:
> Me is resolving correctly for me in stack, card and behavior scripts attached to them. The issue I think was that you cannot seem to reference card <x> of me in a stack script handler. So I created handlers that return the parent card or stack of an object. The object can be the long id of a card even, when getting the parent stack, and that you can use in any reference so far as I know.
>
> All it's doing is forcing the full card ID or stack name resolution so the parser doesn't need to use fuzzy logic.
>
> Bob S


-

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
Well the big thing it deals with is ambiguity. I have a number of substacks which are similar, like data entry forms for different tables in the database, and these have many controls, properties and scripts in common, but also some that are unique to that particular form. If only one of these "form" stacks were allowed to be open at one time, there would be no ambiguity, but I allow multiple "forms" to be opened at the same time, and when I was using modal stacks, this presented a problem. So if at the beginning of a handler I have:

put getParentCard(the long id of me) into tParentCard -- returns the long id of the parent card
put getParentStack(tParentCard) into tParentStack -- returns the long id of the parent stack

then I can make references like so:

button "btnNew" of tParentCard
the databaseSettings of tParentStack
dispatch updateSettings to tParentStack with "true", "all"

Even if another substack is open modally or happens to be the topstack, or if I have an older version of the same application open in Livecode, there can be no ambiguity because everything is resolving to long ids. I am no longer relying on the fuzzy logic of the parser to figure out exactly which object, card or stack I am referring to.

Bob S


> On Nov 1, 2018, at 09:39 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
> Bob, that make sense. But why do need those handlers?
>
> What not just use "of this stack"?
>
> Obviously, I am oblivious to the number contexts where you require:
>
> "...created handlers that return the parent card or stack of an object."
>
> I am curious what they are?
>
> BR
>
> Bob Sneidar via use-livecode wrote:
>> Me is resolving correctly for me in stack, card and behavior scripts attached to them. The issue I think was that you cannot seem to reference card <x> of me in a stack script handler. So I created handlers that return the parent card or stack of an object. The object can be the long id of a card even, when getting the parent stack, and that you can use in any reference so far as I know.
>>
>> All it's doing is forcing the full card ID or stack name resolution so the parser doesn't need to use fuzzy logic.
>>
>> Bob S


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
That should have been the full path to the stack.

Bob S

> On Nov 1, 2018, at 13:02 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> put getParentStack(tParentCard) into tParentStack -- returns the long id of the parent stack


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Mysteries of Me

Pi Digital via use-livecode
In reply to this post by Pi Digital via use-livecode
That make good sense

I may use it some day.  It would allow more handlers in a common back
script/library that did the same thing (anything) when called from
different modules (stacks)

On 11/1/18 10:02 AM, Bob Sneidar via use-livecode wrote:

> Well the big thing it deals with is ambiguity. I have a number of substacks which are similar, like data entry forms for different tables in the database, and these have many controls, properties and scripts in common, but also some that are unique to that particular form. If only one of these "form" stacks were allowed to be open at one time, there would be no ambiguity, but I allow multiple "forms" to be opened at the same time, and when I was using modal stacks, this presented a problem. So if at the beginning of a handler I have:
>
> put getParentCard(the long id of me) into tParentCard -- returns the long id of the parent card
> put getParentStack(tParentCard) into tParentStack -- returns the long id of the parent stack
>
> then I can make references like so:
>
> button "btnNew" of tParentCard
> the databaseSettings of tParentStack
> dispatch updateSettings to tParentStack with "true", "all"
>
> Even if another substack is open modally or happens to be the topstack, or if I have an older version of the same application open in Livecode, there can be no ambiguity because everything is resolving to long ids. I am no longer relying on the fuzzy logic of the parser to figure out exactly which object, card or stack I am referring to.
>
> Bob S


--
Svasti Astu, Be Well!
Brahmanathaswami

Get the SivaSiva app, it's free:
https://www.himalayanacademy.com/apps/sivasiva

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode