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 dras
> 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 of
the caller info which would a
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
__
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
on
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
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:
>> Wh??? So send would but d
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
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 throw an error if a message isn't
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 contex
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.
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 so
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? From
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
following:
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 d
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 parent into a small array
>
> when ca
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 Search
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 can identify, at least for now, th
[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
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 ha
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.
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 t
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 here
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 long
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
___
use-li
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 list
use-livecode@lists.runrev.com
> 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 meaningful ID… stack ID is completely
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 mailin
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 reposito
> 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 ;-)
___
use-livecode mailing li
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
use-livecod
> 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. Instead of returning a string:
>
>
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 q
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):
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 p
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:
method
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 s
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 pF
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
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: wid
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
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 a
>
> 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 wi
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
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
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 se
> 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 the object would mean the string
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 o
> 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 LiveCode… Maybe reference:
get t
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 i
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
> 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 find the word "stack" then return
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
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:
The more we separate our code
> 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 the
stack of the object… we real
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
55 matches
Mail list logo
