Two things to consider:
1. It's almost impossible to catch conflicts with custom properties. They
don't have to be mentioned by name in a script because:
2. It's a feature that custom property names can be stored/referenced using
variables. For example:
repeat for each item P in "left,top"
-- not custom properties, but the same principle applies
set the P of button "example" to 10 * trunc(the P of button
"example" / 10)
end repeat
If you have a large number of custom properties to initialize, this allows
you to do something like:
put "cProp1,23 cProp2,18 cProp3,98" into P
split P using space and comma
repeat for each key K in P
set the K of button "example" to P[K]
end repeat
In neither of these cases would it be easily detectible to the compiler
what (custom) properties are being referenced, and these cases aren't close
to pathological. On the other hand, simply disallowing the use of a
variable to store/reference a (custom) property would be a significant loss
of functionality.
On Tue, Jan 20, 2015 at 2:17 PM, Mike Kerner <mikeker...@roadrunner.com>
wrote:
> ugh. That's an ugly. I'd file a feature request to have the
> parser/compiler catch those for you. I am a big proponent of loose syntax,
> but if it's going to be loose enough that you can do THAT, then you either
> should get an error for misusing the token or it should be smart enough to
> not fail.
>
> On Tue, Jan 20, 2015 at 1:13 PM, Ralph DiMola <rdim...@evergreeninfo.net>
> wrote:
>
> > I just spent an 1.5 hours of "what the heck just happened". My fault but
> > just wanted to let others know.
> >
> > I have a custom stack prop named "pRegion". This worked as expected
> except
> > in one handler. It always returned empty. From either the handler or from
> > the message box while the handler was being debugged or from an answer
> > dialog. Click the stop button in the debugger, then from the message box
> > the
> > custom property is the value the inspector says. Breakpoint on the first
> > line of the mouseup handler and it's gone. Deleted all the code in the
> > handler and it's back even though I examined it before any code was run
> > from
> > the debugger both times.
> > Problem: I had a local of the same name by mistake. I was not even using
> > it.
> > I just deleted it and all was OK. This might be obvious to the more
> > seasoned
> > LiveCoder but to a beginner... not so much
> >
> > Just an FYI
> >
> > Ralph DiMola
> > IT Director
> > Evergreen Information Services
> > rdim...@evergreeninfo.net
> >
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
> and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
