breakpoint on parameter

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps