Parent of Target

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Parent of Target

** Clarence P Martin ** via use-livecode
The more we separate our code/libraries/behaviors from the binary UI, the more I find myself trying to dispatch call backs or other messages back to the group/card/stack that has a behavior and not the individual control: widget/button/field on the card itself, whose job was simply to intercept a mouse event and server as the target in higher switch.  So you need to get the long ID

widget id 1104 of card id 1002 of stack "/Users/Brahmanathaswami/Documents/_Siva-Siva-App/modules/listen/listen.livecode"

# widget is "downloadSelection"

so it seems a bit "hacky" but all I can think of to send a callback to the behavior attached to the card and not the widget itself is:

put the long ID of the target into pRequestedBy

delete word 1 to 4 of pRequestedBy

dispatch "someCommand" to "someOtherStack with  param1, param 2, sRequestedBy

# intent is, once load URL is done to close the download view dispatch update commands aback to the UI that initiated the Download: the stack "listen"

maybe hacky, but simple enough and well, this *is* supposed to be "English like coding"

but sometimes my code seems like "baby xTalk"   is there a better way?

OTOH Baby xTalk is more fun than C++!

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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode

> On 9 Aug 2017, at 1:39 pm, Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
>  is there a better way?

Perhaps you want this?

the long owner of the target

or

the long owner of me

Of course things get a bit more complicated if you want the card of or the stack of the object… we really should put some read only properties in for those...

Cheers

Monte
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
I'm not sure I follow all your explanation but you can refer to the object
that holds the behavior script as "this me".

I still get a kick out of that but it's quite appropriate.



On August 8, 2017 10:41:46 PM Sannyasin Brahmanathaswami via use-livecode
<[hidden email]> wrote:

> The more we separate our code/libraries/behaviors from the binary UI, the
> more I find myself trying to dispatch call backs or other messages back to
> the group/card/stack that has a behavior and not the individual control:
> widget/button/field on the card itself, whose job was simply to intercept a
> mouse event and server as the target in higher switch.  So you need to get
> the long ID

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
I have a function that returns the stack of an object by passing the long id of the object. getParentStack(the long id of me). All it does is parses the long id by using wordOffset to find the word "stack" then returns word tWord to -1 of the long id. Pretty basic.

That method can be used for anything, from the owner to the card to the first group etc. I don't think we need more properties per se.

Bob S


> On Aug 8, 2017, at 20:43 , Monte Goulding via use-livecode <[hidden email]> wrote:
>
>
>> On 9 Aug 2017, at 1:39 pm, Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>>
>> is there a better way?
>
> Perhaps you want this?
>
> the long owner of the target
>
> or
>
> the long owner of me
>
> Of course things get a bit more complicated if you want the card of or the stack of the object… we really should put some read only properties in for those...
>
> Cheers
>
> Monte
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode

> On 10 Aug 2017, at 2:25 am, Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> I have a function that returns the stack of an object by passing the long id of the object. getParentStack(the long id of me). All it does is parses the long id by using wordOffset to find the word "stack" then returns word tWord to -1 of the long id. Pretty basic.
>
> That method can be used for anything, from the owner to the card to the first group etc. I don't think we need more properties per se.

Yes we have these kinds of functions in the ide too. I just think we shouldn’t need something that depends on the format of a long ID to do something so common as to get a reference to the card of a control or stack of anything.

One day I dream of an object reference that we can get and use that is not a string that needs to be resolved every time it’s used but a direct reference to the object. Perhaps if someone tries to do a string operation on it then it would be turned into a long id string just like when someone tries to do “1” + 1 it’s turned into a number. But if it’s just passed around or stored in a custom property then it remains a resolved handle to the object and can cope with things like the ID or name or filename being changed in the session. If we had that we would want things like `is a {stack | card | button …}` and `{stack | card | mainstack} of`.

I have actually thought about whether it would be reasonable for `the long id` to return such an object reference as it would stringify automagically if necessary. However, deleting the object would mean the string form couldn’t be created so that probably wouldn’t work... I think complex objects that handle many object references and the IDE would have a significant bump in speed if we did such a thing.

Cheers

Monte
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
Monte Goulding wrote:

 > I have actually thought about whether it would be reasonable for `the
 > long id` to return such an object reference as it would stringify
 > automagically if necessary....I think complex objects that handle many
 > object references and the IDE would have a significant bump in speed
 > if we did such a thing.

Oh yes please!

Jacque recently showed me the speed difference between explicitly
writing out the element of an object reference:

   get the width of btn 1 of cd 2 of stack "MyStack"

...vs other forms like long IDs:

   put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
   get teh width of tObj

The latter is much slower, yet long IDs are so good to work with.

Anything that can be done to speed up object references would be great.
I'd never before seen the impact until last week's testing, but once I
did I'm now tempted to write tediously long code for those cases where a
lot of objects need to be addressed. Your proposal makes all that go
away, and fast that any form we have now.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On 08/09/2017 01:48 PM, Monte Goulding via use-livecode wrote:

> One day I dream of an object reference that we can get and use that is not a string that needs to be resolved every time it’s used but a direct reference to the object. Perhaps if someone tries to do a string operation on it then it would be turned into a long id string just like when someone tries to do “1” + 1 it’s turned into a number. But if it’s just passed around or stored in a custom property then it remains a resolved handle to the object and can cope with things like the ID or name or filename being changed in the session. If we had that we would want things like `is a {stack | card | button …}` and `{stack | card | mainstack} of`.

...and then...
we could name them 'pointers' and 'handles' and I'd be very happy.
<g>

--
  Mark Wieder
  [hidden email]

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode

> On 10 Aug 2017, at 7:17 am, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> ...and then...
> we could name them 'pointers' and 'handles' and I'd be very happy.
> <g>

Ha… one of the reasons I thought about overloading long ID is because pointer and handle aren’t very LiveCode… Maybe reference:

get the reference of <object>

Using such a reference to a deleted object would need to throw an error I think.

People would need to understand that you couldn’t use such references in delimited lists. So if you wanted a list of object references you would need to use an array.

FWIW the ScriptObject in LCB is basically what I’m talking about but as a regular script value type.

Cheers

Monte
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
 
 

  Pretty funny... reading the conversation and I immediately thought "pointer".
 

 
 

 
 
>  
> On Aug 9, 2017 at 4:17 PM,  <Mark Wieder via use-livecode (mailto:[hidden email])>  wrote:
>  
>  
>  
>  On 08/09/2017 01:48 PM, Monte Goulding via use-livecode wrote:  >  One day I dream of an object reference that we can get and use that is not a string that needs to be resolved every time it’s used but a direct reference to the object. Perhaps if someone tries to do a string operation on it then it would be turned into a long id string just like when someone tries to do “1” + 1 it’s turned into a number. But if it’s just passed around or stored in a custom property then it remains a resolved handle to the object and can cope with things like the ID or name or filename being changed in the session. If we had that we would want things like `is a {stack | card | button …}` and `{stack | card | mainstack} of`. ...and then... we could name them 'pointers' and 'handles' and I'd be very happy. -- Mark Wieder [hidden email] _______________________________________________ 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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode

> On 10 Aug 2017, at 6:48 am, Monte Goulding via use-livecode <[hidden email]> wrote:
>
> I have actually thought about whether it would be reasonable for `the long id` to return such an object reference as it would stringify automagically if necessary. However, deleting the object would mean the string form couldn’t be created so that probably wouldn’t work... I think complex objects that handle many object references and the IDE would have a significant bump in speed if we did such a thing.

Thinking about this some more I wonder if a stringified representation and string representation type could be paired with the object reference so that if you got say the abbreviated id then that would be the stringified representation and if the object is deleted then the stringified representation is used from then on until it is re-resolved (say the stack is reloaded). Then if it is re-stringified then the new representation stored. The only issue here would be any code that relied on the string not changing when you rename etc an object etc but I’m not sure how common that would be. That and there could be quirks like if you get the reference, rename it and then delete it the string representation would probably still be the original name. The general idea though is it would be something like a string is now in the engine. We don’t need to know if under the hood it is currently an 8 bit native string or a 16 bit unicode string.

If we could work out all the little niggles in the idea then it could be that we wouldn’t need to change our code at all (other than to remove all the code which tries to handle name and id changes) which would be nice. Also things like `the target` and `the owner` could seamlessly upgrade to being references.

Cheers

Monte
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
@ Jacque   the behavior is attached to a stack that is not the same stack as the target (a download button) so "this me" won't work

@ Bob  " getParentStack(the long id of me). All it does is parses the long id by using wordOffset to find the word "stack" then returns word tWord to -1 of the long id. Pretty basic."

Awesome: this has been added to the main backscript utilities section… Nandri! (thank you)

@ Monte & Richard

" Monte Goulding wrote:

> I have actually thought about whether it would be reasonable for `the
> long id` to return such an object reference as it would stringify
> automagically if necessary....I think complex objects that handle many
> object references and the IDE would have a significant bump in speed
> if we did such a thing.

Oh yes please!

+1!

Addendum on Scoping

This new "modular" world, of behaviors, libs that have been put into msg path with "start Using" or "insert into back".. text files, multiple binary.livecode stacks -- not substacks as such, but separate.livecode files.
The app is now a complete "environment/framework". With Andre constant warnings along with my experience using globals in this environment gets very dangerous very fast, typically want to use an array to starts holding all kind of things we think we need to reference across many different stacks/libs. Seems OK on the surface, but then as Andre says, if  someGlobalArray["fruit"]  = "apple" when you thought for sure it should now be "orange" then then debugging "hell" door opens. So instead we start sending and dispatching commands, setting up locals in scripts with lots of small

local sCurrentFlavorA

function returnCurrentFlavor
   put sCurrentFlavorA["fruit"]
end  returnCurrentFlavor

So now, with debug on you can trace easily where things are happening.  so some way to track, not only "where did this come from" (which is what debug stepping is really doing) but to look "up"   "Who is asking?"  
would be interesting.

Somehow I think this relates to another Idea I keep having: which is

place group [custom control]  "downloading" of stack "customControlsLibrary onto this card

Where:
a) group "downloading" has progressField, progressTitle, progressBar (ala the lesson on line for load URL which I just copied to the SivaSiva app and modified yesterday) i.e. a customcontrol
b) that group has a behavior
c) that it can be made to magically appear and disappear "anywhere at any time"
d) such that one update updates all future instances.

OK well now we can do that by copying the group dynamically and since after the standalone is built, that group is never saved.. "kinda" works, but in dev I keep getting multiple copies of this group in different stacks…

i.e we already have this with  icons for buttons… you can have a single image + ID for a button that appears on multiple stacks.. change the image and all buttons change.  So why not a phantom group whose "real" presence is a single instance in another stack.  

Perhaps this has nothing to do with the parent of target; but seems all vaguely related.

[/end of babbling about what I do not really understand very well]



On 8/9/17, 6:25 AM, "use-livecode on behalf of Bob Sneidar via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    getParentStack(the long id of me). All it does is parses the long id by using wordOffset to find the word "stack" then returns word tWord to -1 of the long id. Pretty basic.

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
On 08/09/2017 06:24 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

> local sCurrentFlavorA
>
> function returnCurrentFlavor
>     put sCurrentFlavorA["fruit"]
> end  returnCurrentFlavor
>
> So now, with debug on you can trace easily where things are happening.  so some way to track, not only "where did this come from" (which is what debug stepping is really doing) but to look "up"   "Who is asking?"
> would be interesting.

I do use getter and setter routines regularly. I think your function is
useful, but won't by itself get at the question of "who changed that?",
and for that question there are at least two possible methods:

method 1:

local sCurrentFlavorA

command setCurrentFruitFlavorTo pFlavor
   put pFlavor into sCurrentFlavor["fruit"]
end setCurrentFruitFlavorTo

setCurrentFruitFlavorTo "orange"

method 2:

setProp CurrentFruitFlavor pFlavor
   put pFlavor into sCurrentFlavor["fruit"]
end CurrentFruitFlavor

getProp CurrentFruitFlavor
   return sCurrentFlavor["fruit"]
end CurrentFruitFlavor

set the CurrentFruitFlavor of me to "orange"
get the CurrentFruitFlavor of me

By placing breakpoints into either of these methods you can track what
sets the values in the debugger, or by placing logging statements into
either you can display the stack traces as they fly by:

   put pFlavor into sCurrentFlavor["fruit"]
   put the executionContexts & cr after msg

--
  Mark Wieder
  [hidden email]


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On 8/9/17 8:24 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>  the behavior is attached to a stack that is not the same stack as the target (a download button) so "this me" won't work

I think it should...

Object with an assigned behavior:  "me"
Object that contains the behavior script:  "this me"

If the backscript stack holds the behavior script then the stack itself
should be "this me". The target (the download button) which has the
behavior assigned would be "me".

Logically, anyway.

> So instead we start sending and dispatching commands

If the script is in the message hierarchy, I wouldn't think you'd need
to send or dispatch anything, just issue the command normally. You can
debug that pretty easily and there's one less level of abstraction.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
>
> Jacque recently showed me the speed difference between explicitly
> writing out the element of an object reference:
>
>    get the width of btn 1 of cd 2 of stack "MyStack"
>
> ...vs other forms like long IDs:
>
>    put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
>    get teh width of tObj
>
> The latter is much slower, yet long IDs are so good to work with.
>

The only reason this is true is that in the second case you are resolving
the object twice. It is not true in general - the second time the long id
is used it will use the id cache which is constant time, whereas "button n"
is O(n). Try benchmarking repeated use of the stored long id vs the number
version, especially if the numbers are large.

So it's horses for courses. If it's a one-shot object access then the
number form is faster. For repeated use, get the long id.

>
>
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On 2017-08-10 01:47, Monte Goulding via use-livecode wrote:

> Thinking about this some more I wonder if a stringified representation
> and string representation type could be paired with the object
> reference so that if you got say the abbreviated id then that would be
> the stringified representation and if the object is deleted then the
> stringified representation is used from then on until it is
> re-resolved (say the stack is reloaded). Then if it is re-stringified
> then the new representation stored. The only issue here would be any
> code that relied on the string not changing when you rename etc an
> object etc but I’m not sure how common that would be. That and there
> could be quirks like if you get the reference, rename it and then
> delete it the string representation would probably still be the
> original name. The general idea though is it would be something like a
> string is now in the engine. We don’t need to know if under the hood
> it is currently an 8 bit native string or a 16 bit unicode string.

This sounds very much like the idea proposed here -
http://forums.livecode.com/viewtopic.php?f=66&t=15017 - as a reason for
why UUIDs were not necessarily the 'right' approach (and never will be,
IMHO) ;)

This is something which could be done (with the new architecture in 7+,
indeed the potential for it was one of the many many reasons that
motivated the refactor) - however, in reality, we risk changing the
language quite fundamentally. Something which I became acutely aware of
during the refactoring process (partly through direct conversation with
a variety of long-term xTalkers - trying to explain what could become
possible with it).

If we are going to break the everything-but-arrays are strings semantic
then let's do it (1) completely and (2) in a way which ensures we 'bring
everyone with us' (how many VB users didn't move to VB.NET?). [ The
latter point is the most important one, btw ]. 'Creeping' language
changes just don't work - particularly at the core semantic (types, in
this case) level - you risk ending up with something which may be much
more powerful but also much less accessible/easy/familiar/... ]

Indeed, this realisation of the crucial 'semantic gap'* LiveCode Script
has (which is true of 4GLs *in general*) was one of the motivations for
Builder**.

Builder already has the 'object handle' (ScriptObject) idea - so we can
use that to build a library which manages the object references the IDE
holds at any one time. This solves the robustness problem we face in the
IDE and in a way which doesn't require a single change to LCS. (Over
time it could also solve the speed issue too - we implement the parts
which are bottle-necked by ScriptObject<->StringId conversions in LCB so
they aren't necessary). [ Robustness is far more important than speed
here, though ].

In terms of user-code, then yes, there are also user apps which require
this - so we can just make the functionality a user available library
extension when it is mature enough. Users can then evaluate whether it
is 'worth' the extra cognitive cost of using such a thing for their
situation on a per-project basis (just like the IDE - being a LiveCode
Script project itself).

Warmest Regards,

Mark.

* I should stress that what I call a 'semantic gap' does not in any way
make LCS a 'lesser' language - because it really is not. xTalks have
evolved with a different focus from many other languages and fill that
very well, that's all. They make the tasks it is focused on easier, at
the expense of making some other things harder (but only slightly - you
still have the 'ease' of the language as a whole to couch them in).

** I do see a future where there are not two languages - 'Script' and
'Builder' - but only 'LiveCode'. However, that 'unification' has to be
done in a way which does not, in any way, detract from what makes
LiveCode Script what it is (which sounds subjective, but the recent
study released about 'cognitive load' does perhaps suggest a means of
measurement - which starts to make it objective).

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On 2017-08-10 09:32, Ali Lloyd via use-livecode wrote:

>>
>> Jacque recently showed me the speed difference between explicitly
>> writing out the element of an object reference:
>>
>>    get the width of btn 1 of cd 2 of stack "MyStack"
>>
>> ...vs other forms like long IDs:
>>
>>    put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
>>    get teh width of tObj
>>
>> The latter is much slower, yet long IDs are so good to work with.
>>
>
> The only reason this is true is that in the second case you are
> resolving
> the object twice. It is not true in general - the second time the long
> id
> is used it will use the id cache which is constant time, whereas
> "button n"
> is O(n). Try benchmarking repeated use of the stored long id vs the
> number
> version, especially if the numbers are large.
>
> So it's horses for courses. If it's a one-shot object access then the
> number form is faster. For repeated use, get the long id.

Just to expand on what Ali said...

There is an overhead in parsing a long id string - however, that is
proportional to the length of the id string which are generally quite
short. Also, this is purely 'parsing' it is basically munching chars and
branching which means the 'step' taken at each char is very very very
fast. Certainly something which is overwhelmed by whatever operation you
might be doing with the resolved chunk.

What takes up the time in resolving object references is finding the
objects at each step.

If you use the indexed form - e.g. btn 3 - then the time taken is
proportional to the magnitude of the index as the engine has to step
through a list to find the object.

If you use the id form, however, then the lookups are cached at the
stack level after the first time they are resolved. The id of an object
is unique within the confines of a stack, and every stack has a
hash-table which caches id->objectptrs internally.

If you are doing custom control type work (which is where you tend to
have to manage lots of child control references), then I'd generally
suggest not using long ids, but instead just store the id property of
the child object and use explicit syntax:

   control id ... of me -- here I'm assuming that 'me' is a group ;)

The reason is that this is (after the first lookup for any given id/me
pair) a completely constant time lookup:

   - 'me' is stored internally as a direct pointer

   - id's can be looked up in the stack hash table.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
On 2017-08-09 05:39, Sannyasin Brahmanathaswami via use-livecode wrote:
> The more we separate our code/libraries/behaviors from the binary UI,
> the more I find myself trying to dispatch call backs or other messages
> back to the group/card/stack that has a behavior and not the
> individual control: widget/button/field on the card itself, whose job
> was simply to intercept a mouse event and server as the target in
> higher switch.  So you need to get the long ID

I'm not sure I follow the underlying reasoning here - why not just use
'the long id of the target'?*

The message path means that the message will hit the group/card/stack if
not handled in the control (which it won't be, from what you are
saying).

Warmest Regards,

Mark.

* This is the model used in the engine (e.g. for sockets), and in LCB
widgets (which post a message to the script of the widget, which then
filters down the message path in the usual way).

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
Remember that arrays stored as properties provides a kind of scoping. For example 2 stacks can hold the same array but with different values in a property with the same name. The added advantage is they are persistent through idle and you can now check the contents of the properties by drilling down in the property inspector to the value you want to check to see what it contains.

Properties work great as a kind of scoped global.

Bob S


> On Aug 9, 2017, at 18:24 , Sannyasin Brahmanathaswami via use-livecode <[hidden email]> wrote:
>
> Addendum on Scoping
>
> This new "modular" world, of behaviors, libs that have been put into msg path with "start Using" or "insert into back".. text files, multiple binary.livecode stacks -- not substacks as such, but separate.livecode files.
> The app is now a complete "environment/framework". With Andre constant warnings along with my experience using globals in this environment gets very dangerous very fast, typically want to use an array to starts holding all kind of things we think we need to reference across many different stacks/libs. Seems OK on the surface, but then as Andre says, if  someGlobalArray["fruit"]  = "apple" when you thought for sure it should now be "orange" then then debugging "hell" door opens. So instead we start sending and dispatching commands, setting up locals in scripts with lots of small
>
> local sCurrentFlavorA
>
> function returnCurrentFlavor
>   put sCurrentFlavorA["fruit"]
> end  returnCurrentFlavor
>
> So now, with debug on you can trace easily where things are happening.  so some way to track, not only "where did this come from" (which is what debug stepping is really doing) but to look "up"   "Who is asking?"  
> would be interesting.


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
Mark Wieder wrote:

> I do use getter and setter routines regularly. I think your function is
> useful, but won't by itself get at the question of "who changed that?",
> and for that question there are at least two possible methods:
>
> method 1:
>
> local sCurrentFlavorA
>
> command setCurrentFruitFlavorTo pFlavor
>    put pFlavor into sCurrentFlavor["fruit"]
> end setCurrentFruitFlavorTo
>
> setCurrentFruitFlavorTo "orange"
>
> method 2:
>
> setProp CurrentFruitFlavor pFlavor
>    put pFlavor into sCurrentFlavor["fruit"]
> end CurrentFruitFlavor
>
> getProp CurrentFruitFlavor
>    return sCurrentFlavor["fruit"]
> end CurrentFruitFlavor
>
> set the CurrentFruitFlavor of me to "orange"
> get the CurrentFruitFlavor of me

With rare exceptions I use Method 1 almost exclusively.

Method 2 feel more natural in many respects, but suffers from one
drawback critical in some cases:  when lockMessages is true getProp and
setProp won't fire.

Custom handlers will always fire regardless of the current state of
message locking.

This has been discussed before, and IIRC Mark Waddingham expressed an
interest in perhaps reclassifying getProp and setProp from system
messages to custom messages, so they would become as immune to locking
as other custom handlers.  But despite the good intention, it seems the
work involved would have murky non-trivial implications.

So for the sake of robustness (and sanity during debugging when things
go mysteriously wrong), as much as I would prefer to use property syntax
for things that behave like properties, I don't.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Parent of Target

** Clarence P Martin ** via use-livecode
In reply to this post by ** Clarence P Martin ** via use-livecode
Ali Lloyd wrote:

 > Richard wrote
 >> Jacque recently showed me the speed difference between explicitly
 >> writing out the element of an object reference:
 >>
 >>    get the width of btn 1 of cd 2 of stack "MyStack"
 >>
 >> ...vs other forms like long IDs:
 >>
 >>    put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
 >>    get teh width of tObj
 >>
 >> The latter is much slower, yet long IDs are so good to work with.
 >
 > The only reason this is true is that in the second case you are
 > resolving the object twice.

Indeed - a very poor example on my part.  Also "teh" is not a recognized
token. :)


 > It is not true in general - the second time the long id is used it
 > will use the id cache which is constant time, whereas "button n"
 > is O(n). Try benchmarking repeated use of the stored long id vs the
 > number version, especially if the numbers are large.
 >
 > So it's horses for courses. If it's a one-shot object access then the
 > number form is faster. For repeated use, get the long id.

Sounds good, but the benefits of long ID caching have been difficult for
me to measure.

I was exploring this a while back in response to this forum thread:
http://forums.livecode.com/viewtopic.php?f=7&t=29555

Of course object ref performance matters most when you need to traverse
a lot of objects or refer to objects frequently, so my test attempts to
do both:

I made a simple stack with one button containing the script below, and
one group containing 100 buttons.

The script uses three different methods to obtain a property value from
every object in the group, through 100 iterations, for a total of 10,000
accesses with each method.

When I'd posted earlier the property being obtained was the short ID,
which seems a reasonable reflection of time needed to obtain an
arbitrary property value.

After reading your post I changed that to long ID, but see little
difference in relative performance.

How might I measure the benefits of long ID caching?


--=================================================--
local sObjRefsA

on mouseUp
    put 100 into n
    put (the number of btns of grp 1) * n into tIterations
    --------------
    put the millisecs into t
    repeat n
       put ObjRef1() into r1
    end repeat
    put the millisecs - t into t1
    --
    put the millisecs into t
    repeat n
       put ObjRef2() into r2
    end repeat
    put the millisecs - t into t2
    ------------------
    -- Last test requires that we first obtain the object refs to
    -- measure the benefits of long ID caching:
    repeat with i = 1 to the number of btns of grp 1
       put the long id of btn i of grp 1 into sObjRefsA[i]
    end repeat
    --
    put the millisecs into t
    repeat n
       put ObjRef3() into r3
    end repeat
    put the millisecs - t into t3
    --------------------
    set the numberformat to "0.0000"
    put t1/tIterations &" - Method 1 - full expression by number " &cr \
    &   t2/tIterations &" - Method 2 - mixed expression"  &cr \
    &   t3/tIterations &" - Method 3 - long ID only" &cr \
        & (r1 = r3)
end mouseUp


-- Ordinal references all the way down:
function ObjRef1
    put the number of btns of grp 1 into tNumBtns
    repeat with x = 1 to tNumBtns
       put the long id of btn x of grp 1 of cd 1 of stack \
         "objref test" &cr after s
    end repeat
    return s
end ObjRef1


-- Mix of ordinal button with group long ID:
function ObjRef2
    put the long id of grp 1 into tGrpObj
    put the number of btns of tGrpObj into tNumBtns
    repeat with x = 1 to tNumBtns
       put the long id of btn x of tGrpObj &cr after s
    end repeat
    return s
end ObjRef2


-- Long ID:
function ObjRef3
    put the number of btns of grp 1 into tNumBtns
    repeat with x = 1 to tNumBtns
       put the long id of sObjRefsA[x] &cr after s
    end repeat
    return s
end ObjRef3



--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
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
12
Loading...