Re: breakpoint on parameter

[Quentin Long via use-livecode]

sez "J. Landman Gay" :
| On 5/23/17 10:36 AM, Matt Maier via use-livecode 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?
| 
| You can't break for a parameter per se, only at a specified line of 
| script. …
I just had an idea that might be helpful for Matt Maier…

If I'm reading the LC Dictionary aright, the property "executionContexts" 
should be very useful for nailing down which handler did what at whatever time; 
you just need to look at the executionContexts at just the right moment. So, 
use a "send [whatever] in [time]" loop, like so:

on ColorCheck
  if (the color of the specific control) = "gray" then
answer the executionContexts
  end if
  if the optionKey is up then send "ColorCheck" to me in 50 milliseconds
end ColorCheck

Ordinarily, "send [whatever] in [time]" loops are frowned upon because they 
burn cycles gratuitously, thus slowing down the stack's operations. But in this 
case, slowing down the stack's operations should be acceptable, as it gives you 
a better chance of catching the offending command (i.e., the one that's doing 
the color-change) in the act.

Troubleshooting: If what's really happening is an change in the control's blend 
property, that could make the control *appear* to change color while said color 
is actually the same, in which case the "answer the executionContexts" line 
would never execute. If this happens, check for a change in the control's blend 
property, not a change in the control's color property.
   
"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"

Read the webcomic at [ http://www.atarmslength.net ]!

If you like "At Arm's Length", support it at [ 
http://www.patreon.com/DarkwingDude ].

___
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

Re: breakpoint on parameter

[Mark Wieder via use-livecode]

On 05/24/2017 08:23 AM, Mark Waddingham via use-livecode wrote:

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", 

The idePropertyChanged message gets sent to the object which calls 
revIDESubscribe. In that handler you can inspect the malfunctioning 
object's properties.


That's a clever solution. And there's a corresponding revIDEUnsubscribe 
message as well as a revIDEUnsubscribeAll for when you're done. I don't 
believe any of these are documented, but they're useful and, in my case 
at least, essential.


For now the subscribe messages are limited to a predefined set of IDE 
messages, but the long-term plan as I understand it is to open up the 
mechanism to allow for user-defined messages as well.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: breakpoint on parameter

[Mark Waddingham via use-livecode]

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", 

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

Re: breakpoint on parameter

[Mark Waddingham via use-livecode]

On 2017-05-23 17:57, Mark Wieder via use-livecode wrote:

On 05/23/2017 08:45 AM, Richard Gaskin via use-livecode wrote:


There's a request to allow getProp and setProp for built-in object
properties:
http://quality.livecode.com/show_bug.cgi?id=3126


...and it's from  2005, rev version 2.6...


The ball was dropped on that one somewhat:

  http://forums.livecode.com/viewtopic.php?f=66=14819

Monte submitted a PR, which kinda got lost in the huge behemoth that was 
the refactor. Definitely something to revisit at some point.


Of course, the fact I've still not managed to figure out a solution to:

  http://forums.livecode.com/viewtopic.php?f=66=18048

Irks me greatly.

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

Re: breakpoint on parameter

[Dr. Hawkins via use-livecode]

On Tue, May 23, 2017 at 3:39 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> (There are ways to break when certain variables change but that's
> different.)


Has that bug ever been fixed?

I never found the IDE crashing a useful way to debug :)


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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

Re: breakpoint on parameter

[J. Landman Gay via use-livecode]

On 5/23/17 10:36 AM, Matt Maier via use-livecode 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?


You can't break for a parameter per se, only at a specified line of 
script. (There are ways to break when certain variables change but 
that's different.) What I'd do is use the Find and Replaced dialog in 
the Edit menu to search for a relevant term. If you are using the color 
constant "gray" then search for that, otherwise search for the RGB 
value. Set the checkboxes to search only the scripts.


You'll get a list of all script references to the color and you can 
either break at those lines, or just look at them to see which ones are 
making the change.


You could also do a script search for the control's name and check every 
instance of that.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: breakpoint on parameter

[Mark Wieder via use-livecode]

On 05/23/2017 08:45 AM, Richard Gaskin via use-livecode wrote:


There's a request to allow getProp and setProp for built-in object
properties:
http://quality.livecode.com/show_bug.cgi?id=3126


...and it's from  2005, rev version 2.6...

--
 Mark Wieder
 ahsoftw...@gmail.com

___
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

Re: breakpoint on parameter

[Richard Gaskin via use-livecode]

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.


Perhaps Mark Waddingham could offer insight on this.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

breakpoint on parameter

[Matt Maier via use-livecode]

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?
___
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