Every now and again, I wonder why certain properties are not available in
LC. The ones that puzzles me the most are the owning card and owning stack
of an object.
Maybe it's just the kind of tools I write but I frequently need to get that
information.
I have written a couple of handlers to get t
Seems like "this card" would be useful, or, you could just get the long
name of the object which contains a small to big list of owning objects
starting with the object itself.
On Sat, Dec 6, 2014 at 6:03 PM, Peter Haworth wrote:
> Every now and again, I wonder why certain properties are not ava
if there is indeed only one of each, then the "owner"
is just that, the card and the stack.
Craig
-Original Message-
From: Mike Bonner
To: How to use LiveCode
Sent: Sat, Dec 6, 2014 11:17 pm
Subject: Re: Missing properties
Seems like "this card" would be useful
On Sat, Dec 6, 2014 at 8:03 PM, Peter Haworth wrote:
> Every now and again, I wonder why certain properties are not available in
> LC. The ones that puzzles me the most are the owning card and owning stack
> of an object.
>
Do you mean some shortcut to get the owning card no matter what? If you
On Sun, Dec 7, 2014 at 4:47 AM, Geoff Canyon wrote:
> If the object in question is inside a group, you'd have to recurse your way
> out, or you could use:
>
> put word -5 to -1 of the long id of btn 1
>
I actually define a shId() function for figuring these things out and
tracking them:
unct
Thanks for the suggestions, they're pretty much variations on what I'm
already doing.
My point was that a lot of people have spent time coming up with various
ways of getting a control's owning card/stack which to my way of thinking
means there should be a built-in way of doing it.
Pete
lcSQL Sof
On Sun, Dec 7, 2014 at 12:12 PM, Peter Haworth wrote:
> My point was that a lot of people have spent time coming up with various
> ways of getting a control's owning card/stack which to my way of thinking
> means there should be a built-in way of doing it.
>
Agreed -- here's hoping the new synta
On 8 Dec 2014, at 6:01 am, Geoff Canyon wrote:
> On Sun, Dec 7, 2014 at 12:12 PM, Peter Haworth wrote:
>
>> My point was that a lot of people have spent time coming up with various
>> ways of getting a control's owning card/stack which to my way of thinking
>> means there should be a built-in
r, reside in. But if there is indeed only one of each, then the
> "owner" is just that, the card and the stack.
>
>
> Craig
>
>
>
> -Original Message-
> From: Mike Bonner
> To: How to use LiveCode
> Sent: Sat, Dec 6, 2014 11:17 pm
> Subject: Re: Missin
On Sun, Dec 7, 2014 at 5:17 PM, Monte Goulding
wrote:
> On the whole I'm not sure if there's a big advantage to implementing it in
> the engine but like I said it's not difficult.
I'm assuming that once we have the new syntax definition capability
something like this won't require an engine cha
On 8 Dec 2014, at 4:34 pm, Geoff Canyon wrote:
>> On the whole I'm not sure if there's a big advantage to implementing it in
>> the engine but like I said it's not difficult.
>
>
> I'm assuming that once we have the new syntax definition capability
> something like this won't require an engine
On Mon, Dec 8, 2014 at 1:40 AM, Monte Goulding
wrote:
> I would expect adding a property to all objects to still need do be done
> in the engine.
Why? I know we don't have detailed documentation on the syntax morphing
functionality, but why would this be any different than the other examples
th
On Sun, Dec 7, 2014 at 7:47 AM, Geoff Canyon wrote:
> If the object in question is inside a group, you'd have to recurse your
> way out, or you could use:
>
> put word -5 to -1 of the long id of btn 1
>
> or if you prefer:
>
> put word -5 to -1 of the long name of btn 1
>
> (the second wo
I haven’t been following this thread closely but the goal is to get the id
and/or name of the card on which a controls sits, yes?
If so, wouldn’t the following 2 functions work?
# pObj is a long id control reference
function cardOwnerID pObj
set the wholeMatches to true
return char offset(
On Mon, Dec 8, 2014 at 5:33 PM, Scott Rossi wrote:
> Admittedly, the cardOwnerID function could fail if a control was located
> within a nested group that was explicitly named “card id” but. . .
>
Exactly why I did it the way I did. I do like the use of the id in
returning the name, and it occur
On 9 Dec 2014, at 1:48 am, Geoff Canyon wrote:
> Why? I know we don't have detailed documentation on the syntax morphing
> functionality, but why would this be any different than the other examples
> that have been given of how we'll be able to tweak the language? Depending
> on the implementati
Monte Goulding wrote:
> Well... I could be wrong but I expect that we will get widgets (a way
> to create new object types) and then more general extensions to
> declare command syntax but I'm not expecting to be able to add a
> property to an existing object. As I said I could be wrong...
I don'
On 10 Dec 2014, at 10:31 am, Richard Gaskin wrote:
> Given this, Geoff's function seems like a good solution. Whether it's
> written in fancy v8 syntax or the syntax we have doesn't matter much to me
> personally; it gets the job done.
Yep, I originally said I didn't really know if it were a
It's been a long time since I saw anything on the syntax extension
functionality, but my recollection was that it was supposed to be the
all-singing, all-dancing wonder of the universe -- meaning that if I wanted
to use a C-like dot-notation (I don't, usually) that would be easy to
build. And that
Geoff Canyon wrote:
It's been a long time since I saw anything on the syntax extension
functionality, but my recollection was that it was supposed to be the
all-singing, all-dancing wonder of the universe -- meaning that if I wanted
to use a C-like dot-notation (I don't, usually) that would be e
On Tue, Dec 9, 2014 at 11:32 PM, Geoff Canyon wrote:
> Is there a more-recent-and-detailed spec that confirms or denies this? I'm
> (non)patiently awaiting the ability to create inline if statements, default
> parameter values, and multiple assignments.
>
> put (if x = y then 6 else 7) into z
> f
On 10/12/2014 07:32, Geoff Canyon wrote:
Is there a more-recent-and-detailed spec that confirms or denies this? I'm
(non)patiently awaiting the ability to create inline if statements, default
parameter values, and multiple assignments.
put (if x = y then 6 else 7) into z
function getColumn pDat
On Wed, Dec 10, 2014 at 12:16 PM, Richard Gaskin wrote:
> The main goal of OL is two-fold: to provide OS API access, and to allow
> custom components (libraries, widgets, etc.) to be integrated as smoothly
> in usage as engine-native routines and objects.
I don't remember it being limited to t
Geoff Canyon wrote:
> On Wed, Dec 10, 2014 at 12:16 PM, Richard Gaskin wrote:
>
>> The main goal of OL is two-fold: to provide OS API access, and
>> to allow custom components (libraries, widgets, etc.) to be
>> integrated as smoothly in usage as engine-native routines and
>> objects.
>
> I don'
On Wed, Dec 10, 2014 at 3:50 PM, Richard Gaskin
wrote:
> If longevity of language features is inversely proportionate to their
> value, C must be a total waste of time. :)
>
Ha -- of course I'm not suggesting that; anyone who wants to take away
repeat for each or URL syntax will have to fight me
On Wed, Dec 10, 2014 at 2:19 PM, Geoff Canyon wrote:
> Basically any time a significant number of developers are expressing a
> single concept in more than one line, that's an opportunity to create a
> simpler, more powerful syntax. You know I could list hundreds of
> possibilities, and the truth
That makes my toes curl reading it.
Bob S
On Dec 10, 2014, at 14:19 , Geoff Canyon
mailto:gcan...@gmail.com>> wrote:
How about
making item take an argument?
put item("|") 2 to 3 of item(";") 2 of
"test|this|thing;one|more|string|here;final|string"
puts "more|string"
On Wed, Dec 10, 2014 at 10:16 AM, Richard Gaskin wrote:
> Right now most of what they do has to be done in C++, while most of what
> we do we get to do in LiveCode. Once OL is available, the core dev team
> gets to spend more time doing development in LiveCode itself, meaning that
. . . the e
28 matches
Mail list logo