On 2017-05-23 17:45, Richard Gaskin via use-livecode wrote:
Matt Maier wrote:
I want to find out which parts of my code are making changes to a
control's parameter. Specifically, I've got an arrow that I want
to be black, and it is black when it's created, but then it turns
gray. I can't find the script that's turning it gray.
I don't know where to put a breakpoint in the script.
Can I put a breakpoint on that control's color parameter, so execution
stops whenever something modifies it and goes to the script that's
doing the modification?
There's a request to allow getProp and setProp for built-in object
properties:
http://quality.livecode.com/show_bug.cgi?id=3126
I would imagine this is a non-trivial request, given what I'm guessing
would be performance penalties.
I don't think the performance penalty is necessarily an issue any more
(see forum thread I posted in another reply).
I did something years ago to how handlers in the message path worked
(changed the search from linear to binary-per-handler-type) - I didn't
think anything of it at the time (didn't even mention it). However, it
has vastly reduced the overhead of dispatching a message through the
message path.
Now, there are potentially other dragons lurking there with the request
- in terms of interpretation of tokens which the engine reserves to
itself, and the order in which the engine does things currently. I'd be
a little concerned that either might cause significant
backwards-compatibility issues. However, that just means it needs more
thought and validation.
Perhaps Mark Waddingham could offer insight on this.
In terms of the original question - it is certainly worth of a
enhancement request (to hook up a debug message for 'control property
changed' situation, like we have one for variables).
Right now, though there might be a way in the IDE by using an IDE
mechanism - the IDE has an API allowing an object to subscribe to a
message when any properties of that object change:
revIDESubscribe "idePropertyChanged", <long id of target object>
The idePropertyChanged message gets sent to the object which calls
revIDESubscribe. In that handler you can inspect the malfunctioning
object's properties.
It might not be fine-grained enough (the engine coalesces such messages
otherwise they would flood the IDE and grind things to a halt) - but it
*might* give you some insight.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
