breakpoint on parameter
mark at livecode.com
Wed May 24 11:23:07 EDT 2017
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
> 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
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
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.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode