Re: Parent of Target

On Wed, Aug 23, 2017 at 1:30 PM, Monte Goulding via use-livecode < use-livecode@lists.runrev.com> wrote: > We could parse the message being sent and check if there’s a handler that > can handle it at the time it’s being sent but that would be a dangerous > change > > Wouldn't it be a bit less

Re: Parent of Target

> On 24 Aug 2017, at 2:07 am, Mark Wieder via use-livecode > wrote: > > Good to know. Yeah, that's weird. It’s not _that_ weird. Using in time there’s no context to throw an error on at the time the handler is sent… Of course pending messages could keep track

Re: Parent of Target

On 08/23/2017 08:23 AM, Trevor DeVore via use-livecode wrote: That is correct, as long as you aren’t using `in time` with `send`. The following script won’t cause an error until the last `send`: Good to know. Yeah, that's weird. -- Mark Wieder ahsoftw...@gmail.com

Re: Parent of Target

On 08/23/2017 08:50 AM, Bob Sneidar via use-livecode wrote: This is actually useful. Let's say you have some fields which do some basic validations against database table constraints and some that do not require them. You could simpy dispatch a command to validate to all fields and only the

Re: Parent of Target

This is actually useful. Let's say you have some fields which do some basic validations against database table constraints and some that do not require them. You could simpy dispatch a command to validate to all fields and only the ones which need to will handle the message. I like it. Bob S

Re: Parent of Target

Odd. I wouldn't have guessed the dependence on "in time" for the send command. Bill P William Prothero http://es.earthednet.org > On Aug 23, 2017, at 8:22 AM, Mark Wieder via use-livecode > wrote: > >> On 08/23/2017 07:59 AM, Bob Sneidar via use-livecode wrote:

Re: Parent of Target

On Wed, Aug 23, 2017 at 9:59 AM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Wh??? So send would but dispatch won't? > That is correct, as long as you aren’t using `in time` with `send`. The following script won’t cause an error until the last `send`: on mouseUp

Re: Parent of Target

On 08/23/2017 07:59 AM, Bob Sneidar via use-livecode wrote: Wh??? So send would but dispatch won't? Bob S On Aug 23, 2017, at 06:21 , Trevor DeVore via use-livecode wrote: I'm in the habit of using "dispatch" as it mimics how the engine works and won't

Re: Parent of Target

OH! "This sends the message down the normal message path starting at the object containing the script. " And here I've been thinking that a target was required for specificity, because of this in the dictionary: "If no target is specified, the message is sent to ' me '. In the

Re: Parent of Target

Wh??? So send would but dispatch won't? Bob S > On Aug 23, 2017, at 06:21 , Trevor DeVore via use-livecode > wrote: > > I'm in the habit of using "dispatch" as it mimics how the engine works and > won't throw an error if a message isn't handled.

Re: Parent of Target

I have that very thing. I call it searchBar. It looks pretty much like a search field from a browser or Finder window (in a somewhat earlier version of the OS) and it's designed to retrieve data and update a datagrid. I would post the rather simple code, except it is dependent on sqlYoga and

Re: Parent of Target

On Wed, Aug 23, 2017 at 1:33 AM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > On 8/22/17 11:42 PM, Trevor DeVore via use-livecode wrote: > > Why do you need to turn > > the long id of the parent into a small array and dispatch to to any > object > > along the path?

Re: Parent of Target

On 8/23/17 1:33 AM, J. Landman Gay via use-livecode wrote: On 8/22/17 11:42 PM, Trevor DeVore via use-livecode wrote: Why do you need to turn the long id of the parent into a small array and dispatch to to any object along the path? From the search custom control I would just do the

Re: Parent of Target

On 8/22/17 11:42 PM, Trevor DeVore via use-livecode wrote: Why do you need to turn the long id of the parent into a small array and dispatch to to any object along the path? From the search custom control I would just do the following: dispatch "behaviorSearchAndFilter" This sends the message

Re: Parent of Target

On Tue, Aug 22, 2017 at 6:11 PM, Sannyasin Brahmanathaswami via use-livecode wrote: > > > in this case behavior_SearchAndFilter is attache to the searhView custom > control > > yep I plan that simple dispatch > > hence my function to turn the long idea of the

Re: Parent of Target

Trevor I'm sorry I muddied the waters by using the word "widget" which I have carelessly tossed around in the past for "small group of objects that team up for a job" But really widgets are widgets now and what I mean is "custom Control" You understand me very well…. The card or

Re: Parent of Target

On Tue, Aug 22, 2017 at 3:24 PM, Sannyasin Brahmanathaswami via use-livecode wrote: > > See earlier longer memo. > USE CASE aka "Problem to Solve" > > is a frame work with multiple stacks/aka "modules" with content. > > Search will be a global requirement. > > I

Re: Parent of Target

[ignore previous post… hit send prematurely] [@ Trevor if you have thoughts based on your experience with Levure… love to hear the ] Disclaimer: this my first time ever doing something with such a huge, modular architect, all previous experience to data has been in 1 Stack with Many Cards = 1

Re: Parent of Target

On 08/22/2017 12:53 PM, Sannyasin Brahmanathaswami via use-livecode wrote: Mark Wieder via use-livecode" wrote: >># do different things based on calling context. That's exactly the opposite of what behaviors are for. BR: ?? but a behavior may contain a script with a mouseup

Re: Parent of Target

Mark Wieder via use-livecode" wrote: >># do different things based on calling context. That's exactly the opposite of what behaviors are for. BR: ?? but a behavior may contain a script with a mouseup handler at that responds to different targets with different actions/results.

Re: Parent of Target

On 08/21/2017 12:54 PM, J. Landman Gay via use-livecode wrote: # do different things based on calling context. That's exactly the opposite of what behaviors are for. I'm not sure I follow the underlying reasoning here Thank you. That was my reaction as well. B- what problem are you

Re: Parent of Target

I don't understand quite what you're trying to do. If this is a behavior, the calling context is "me" or the "long name of me", isn't it? Also, why store it? It's always there. I'm likely missing something. On 8/21/17 1:35 PM, Sannyasin Brahmanathaswami via use-livecode wrote: Back at it

Re: Parent of Target

Back at it here with attempst to make "generic" behaviors as text only stacks that can serve as slaves "all over the place" So this is all about the calling context/target. I wonder If I am working too hard here, may be useful to have the calling context ready for a dispatch, to parse the

Re: Parent of Target

On 08/10/2017 12:10 PM, Richard Gaskin via use-livecode wrote: Indeed - a very poor example on my part. Also "teh" is not a recognized token. :) Yes, but if we're looking for common code patterns... -- Mark Wieder ahsoftw...@gmail.com ___

Re: Parent of Target

AHH HAAH HAHAHAA ! I have often thought of pointing that out. :-) Bob S > On Aug 10, 2017, at 12:10 , Richard Gaskin via use-livecode > wrote: > > Also "teh" is not a recognized token. :) ___ use-livecode mailing

Re: Speed of control lookup (Was Re: Parent of Target)

> On 12 Aug 2017, at 7:26 pm, Mark Waddingham via use-livecode > wrote: > > I'd be happier about introducing a new id if we could solve the multiple > mainstack with same name issue too (or at least get a step closer to it) Hmm… what about giving stacks a

Re: Speed of control lookup (Was Re: Parent of Target)

On 08/12/2017 02:26 AM, Mark Waddingham via use-livecode wrote: I'd be happier about introducing a new id if we could solve the multiple mainstack with same name issue too Yes, please. -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode

Re: Speed of control lookup (Was Re: Parent of Target)

On 2017-08-11 23:58, Monte Goulding via use-livecode wrote: That would mean speed improvements could be done on an object reference that is relatively robust to changes in the object tree and unless you are creating an IDE you would be very unlikely to need to do the LCB object reference

Re: Speed of control lookup (Was Re: Parent of Target)

> On 12 Aug 2017, at 8:11 am, Mark Wieder via use-livecode > wrote: > >> Hmm… Would it be a good idea to create a new ID form with the bare minimum >> to identify an object. > > > UUID > Let’s not start that again ;-)

Re: Speed of control lookup (Was Re: Parent of Target)

On 08/11/2017 02:58 PM, Monte Goulding via use-livecode wrote: Hmm… Would it be a good idea to create a new ID form with the bare minimum to identify an object. UUID -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list

Re: Speed of control lookup (Was Re: Parent of Target)

> On 12 Aug 2017, at 1:23 am, Mark Waddingham via use-livecode > wrote: > > It has also suggested (to me, at least) a slightly different approach - we > make the return value of the 'long id' property of objects what you might > call a StringyLongId value.

Re: Fwd: Speed of control lookup (Was Re: Parent of Target)

On 2017-08-11 14:57, Mark Waddingham via use-livecode wrote: The question of course is 'how fast could we get long id parsing to be' (as that is the bottleneck here, or at least appears to be). Okay so I got stuck on what I am *meant* to be doing, so spent a little time trying to answer this

Fwd: Speed of control lookup (Was Re: Parent of Target)

On 2017-08-11 11:12, Mark Waddingham via use-livecode wrote: On 2017-08-10 21:10, Richard Gaskin via use-livecode wrote: How might I measure the benefits of long ID caching? Here is perhaps a better set of simple benchmarks to compare approaches to lookup (related to ids, anyway):

Re: Parent of Target

On 2017-08-10 21:10, Richard Gaskin via use-livecode wrote: How might I measure the benefits of long ID caching? It isn't long ids which are cached - it is ids. I made a few adjustments, tweaked a few things to remove some overheads which aren't relevant here: private function MarkObjRef1

Re: Parent of Target

On 10/08/2017 18:44, Richard Gaskin via use-livecode wrote: 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:

Re: Parent of Target

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

Re: Parent of Target

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

Re: Parent of Target

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

Re: Parent of Target

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:

Re: Parent of Target

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

Re: Parent of Target

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

Re: Parent of Target

> > 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

Re: Parent of Target

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

Re: Parent of Target

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

Re: Parent of Target

@ 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

Re: Parent of Target

> On 10 Aug 2017, at 6:48 am, Monte Goulding via use-livecode > 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

Re: Parent of Target

Pretty funny... reading the conversation and I immediately thought "pointer". > > On Aug 9, 2017 at 4:17 PM, (mailto:use-livecode@lists.runrev.com)> wrote: > > > > On 08/09/2017 01:48 PM, Monte Goulding via use-livecode wrote: > One day I > dream of an

Re: Parent of Target

> On 10 Aug 2017, at 7:17 am, Mark Wieder via use-livecode > wrote: > > ...and then... > we could name them 'pointers' and 'handles' and I'd be very happy. > Ha… one of the reasons I thought about overloading long ID is because pointer and handle aren’t very

Re: Parent of Target

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

Re: Parent of Target

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 necessaryI think complex objects that handle many > object references and the IDE would have a significant bump

Re: Parent of Target

> On 10 Aug 2017, at 2:25 am, Bob Sneidar via use-livecode > 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

Re: Parent of Target

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

Re: Parent of Target

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 wrote:

Re: Parent of Target

> On 9 Aug 2017, at 1:39 pm, Sannyasin Brahmanathaswami via use-livecode > 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