You mean widget instances I presume because widgets have their own reverse
domain based naming convention/kind.
I suspect it would be useful to use some part of the widget name in the
instance name of a widget given all widgets are referred to as widget so
reading the code it may be hard to wor
OK Monte how about naming convention for widgets?
I currently prepend widget names with “wj” - what do the rest of use
This is all great fuel for the scripting style panel at the conference. Also we
have:
- strict compilation
- being even stricter by also declaring repeat loop iteration var
J. Landman Gay wrote:
> On July 8, 2016 5:35:16 PM Dar Scott wrote:
>
>> I'm sorry I won't be there to throw candy when style suggestions
>> seem legalistic. (Don't tell Richard and Ken, but I often use
>> naming conventions for handlers over a few lines, and even sometimes
>> for tiny ones. I
On July 8, 2016 5:35:16 PM Dar Scott wrote:
I'm sorry I won't be there to throw candy when style suggestions seem
legalistic. (Don't tell Richard and Ken, but I often use naming
conventions for handlers over a few lines, and even sometimes for tiny
ones. I guess I'm being won over as I get
On 07/08/2016 01:48 PM, Monte Goulding wrote:
- being even stricter by also declaring repeat loop iteration variables (I do
this)
I think that might lead to trouble in giving the sense that loop
iterators are of the same class as other variables, whereas writing to a
loop iterator can be a
On 07/08/2016 09:57 AM, J. Landman Gay wrote:
We are all odd in our own way, but as long as we're consistently odd it
works.
I want the t-shirt.
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Pleas
I think "block" is good in your usage. My sense is just twisted to fit my
warped way of looking at things.
> On Jul 8, 2016, at 5:08 PM, Monte Goulding wrote:
>
>
>> On 9 Jul 2016, at 8:33 AM, Dar Scott wrote:
>>
>>> - declaring variables at the top of the handler or in the block they ar
> On 9 Jul 2016, at 8:33 AM, Dar Scott wrote:
>
>> - declaring variables at the top of the handler or in the block they are
>> used. Ali and I do the latter and Peter B thinks it's poor style because we
>> don't have block scoped variables.
>
> I usually write small handlers so it doesn't mat
> On Jul 8, 2016, at 2:48 PM, Monte Goulding wrote:
>
> This is all great fuel for the scripting style panel at the conference. Also
> we have:
>
> - strict compilation
On some days I need this a lot.
> - being even stricter by also declaring repeat loop iteration variables (I do
> this)
I think that is much more common than the c thing.
Sent from my iPhone
> On 9 Jul 2016, at 2:57 AM, J. Landman Gay wrote:
>
> For now I just name the button with a trailing "behavior" string,, i. e.,
> "scrollBehavior".
___
use-livecode mailing li
This is all great fuel for the scripting style panel at the conference. Also we
have:
- strict compilation
- being even stricter by also declaring repeat loop iteration variables (I do
this)
- declaring variables at the top of the handler or in the block they are used.
Ali and I do the latter a
Richard Gaskin writes:
>
> J. Landman Gay wrote:
>
> > Since behavior scripts are only referenced in a "set the behavior"
> > statement, I'm not sure where you'd use an initial flag.
>
> Not in code, just in the object name.
I use the word "behavior" in the object name, as in
button "btnSt
J. Landman Gay wrote:
> Since behavior scripts are only referenced in a "set the behavior"
> statement, I'm not sure where you'd use an initial flag.
Not in code, just in the object name.
> But if I ever need one, I'd use "b" for "behavior".
I could, but I'm still holding out hope that the o
You old OCDer, you. :-) Since behavior scripts are only referenced in a
"set the behavior" statement, I'm not sure where you'd use an initial flag.
But if I ever need one, I'd use "b" for "behavior". For now I just name
the button with a trailing "behavior" string,, i. e., "scrollBehavior".
J. Landman Gay wrote:
I think we're pretty evenly split between "c" and "u". I prefer "c" because
it is, after all, a custom property. Those who migrated from SuperCard
often prefer "u" because over there, I believe, they are called user
properties.
Richard's guide is pretty good and I follow t
I think we're pretty evenly split between "c" and "u". I prefer "c" because
it is, after all, a custom property. Those who migrated from SuperCard
often prefer "u" because over there, I believe, they are called user
properties.
Richard's guide is pretty good and I follow the other conventions
m: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Monte Goulding
Sent: vrijdag 8 juli 2016 04:19
To: How to use LiveCode
Subject: Re: Get fillGradient props
> On 8 Jul 2016, at 10:00 AM, Alex Tweedly wrote:
>
> What do you use for handler-local variables ?
`t` for
> On 8 Jul 2016, at 10:00 AM, Alex Tweedly wrote:
>
> What do you use for handler-local variables ?
`t` for temporary. I believe we fairly closely follow Richard’s scripting style
guide http://fourthworld.com/embassy/articles/scriptstyle.html#Variables
However the team does use `c` instead of
Ah, it was u not c thats right. Thanks richard, that and "extending the
message path" stuff helped me get my grok on. I think I saw c being used
for custom properties somewhere else and it stuck for some reason.
On Thu, Jul 7, 2016 at 7:51 PM, stephen barncard <
stephenrevoluti...@barncard.com>
RG:
"You can quickly identify whether a variable is local or global, or whether
it was passed in as an argument, if you preceed the descriptive name with a
lower-case letter to determine its type."
Char Meaning Example
g
Global variable gMyGlobal
t
Local ("temporary") variable tMyVar
s
Script-l
from Richard Gaskin:
http://www.fourthworld.com/embassy/articles/scriptstyle.html
Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
On Thu, Jul 7, 2016 at 6:41 PM, Mike Bonner wrote:
> Somewhere I once ran across a list of suggested lc naming conventions, it
> helped me greatly. If I recal
Somewhere I once ran across a list of suggested lc naming conventions, it
helped me greatly. If I recall it was s for script locals, t for handler
locals (t for temporary) g for globals, k for constants, c for custom
properties. and I don't know if it was in the same list, but I add a
trailing A fo
What do you use for handler-local variables ?
Thanks
Alex
On 07/07/2016 23:16, Monte Goulding wrote:
On 8 Jul 2016, at 7:52 AM, Scott Rossi wrote:
I've always thought lowercase "L" is a poor choice to prefix a variable
name. Is it an L? It is a capital i? Is it a pipe?
For what it’s worth
On July 7, 2016 4:47:35 PM Sannyasin Brahmanathaswami wrote:
Sheesh… I gotta stick to conventions better.
I think I like jacque's using "s" as the being character for script local
variable.
"l" for "local" just disappeared or looks like a "t"
I got it from Mark Waddingham. He's always rig
> On 8 Jul 2016, at 7:52 AM, Scott Rossi wrote:
>
> I've always thought lowercase "L" is a poor choice to prefix a variable
> name. Is it an L? It is a capital i? Is it a pipe?
For what it’s worth we use `s` in the team for script locals. There are some
older scripts like libURL that use some
Thanks Mark… I'll try it… too many hours at the screen all the letters start
looking the same.. so this could help guard against the "stupido's"
From: use-livecode on behalf of Mark
Wieder
Reply-To: How LiveCode
Date: Thursday, July 7, 2016 at 11:44 AM
To: How LiveCo
>sCurrentObjectProperties is better
>
>
>
>From: use-livecode on behalf of
>Scott Rossi
>Reply-To: How LiveCode
>Date: Thursday, July 7, 2016 at 11:41 AM
>To: How LiveCode
>Subject: Re: Get fillGradient props
>
>You have a typo in your variable name lCurrentOb
ehalf of Scott
Rossi
Reply-To: How LiveCode
Date: Thursday, July 7, 2016 at 11:41 AM
To: How LiveCode
Subject: Re: Get fillGradient props
You have a typo in your variable name lCurrentObjectProperties when you
put the keys but it looks like things should still work.
This works here with a test gr
Sannyasin Brahmanathaswami writes:
>
> Goal: get an explicit list of gradient properties from an object.
>
>
> command getGradientProps
>
> set the defaultstack to the topstack
>
> put the fillGradient of graphic "portal-title-bkgnd" into
lCurrentObjectProperties
>
> put the keys of tCurren
You have a typo in your variable name lCurrentObjectProperties when you
put the keys but it looks like things should still work.
This works here with a test graphic:
on mouseUp
put the fillGradient of graphic 1 into theCurrentObjectProperties
repeat for each key x in theCurrentObjectPropert
30 matches
Mail list logo
