A real switch to turn off system globals

[dunbarx]

This issue has popped up a couple of times.

When debugging, a long list of system globals appears in the variable pane above ones own variables. The ability to hide these is VERY convenient. The option "show globals" in the "script editor" pane of LC preferences doesn't cut it.

There is a wonderful workaround (compliments of Thierry), but involves modifying the script of the "revDebugger" stack. Not necessarily for the faintHearted.

The feature request? Make this happen in the preferences.

Craig Newman

[spencer]

So, I am really new to a programmable developers' environment. Why not check the "LiveCode UI elements appear in list of stacks", find what is providing that list, and putting in a switch yourself?

[shaosean]

You can always make a plugin that modifies the IDE in memory only.. Just use a front/back script or library to do what you need..

[dunbarx]

Shaosean.

Do you mean a plug-in that offers the choice of modifying the scriptDebugger script each session, then restoring it upon quitting? Certainly an option if that is what you meant.

I just changed it permanently.

[shaosean]

Yeah, on the fly. If you send me your changes I can look in to making a plugin for other users who are less inclined to make the modifications to the IDE.

[dunbarx]

Shaosean.

With a "tAlternateHandler" stored in a custom property, would you do something like this?

Code: Select all

on mouseUp
   answer "Hide System Globals?" with "Hide" or "Cancel"
   if it is "hide" then
      put the script of stack "revDebugger" into temp
      get wordoffset("revDebuggerValidGlobalNames",temp)
      put  it into startWord
      get wordoffset("revDebuggerValidGlobalNames",temp,startWord)
      put it + startWord into endWord
      
      put tAlternateHandler into word startWord - 1 to endWord of temp --to catch "on"
      set the script of stack "revDebugger" to temp
   end if
end mouseUp

And then automatically restore the original upon quitting?

Or just store both the entirety of the original and the alternate scripts in custom properties and set and reset the script of the revDeBugger stack?

The alternate handler is:

Code: Select all

function revDebuggerValidGlobalNames
   local tGlobalsRaw
   put the globals into tGlobalsRaw
   
   replace comma with return in tGlobalsRaw
  
   filter tGlobalsRaw without "*(x86)"
    filter tGlobalsRaw without "$*"
     filter tGlobalsRaw without "grev*"
   replace return with comma in tGlobalsRaw
   
   return tGlobalsRaw
end revDebuggerValidGlobalNames

Craig

[shaosean]

Considering I have never used the debugger nor looked at the code used by it, I am not too certain how I would need to go about doing it There are two ways that I like to go about modifying the IDE.. The first way is to install a front script to intercept the commands, but some times this is not doable (stilly "private" handlers).. The second way is to replicate the whole feature and just to replace the original (in memory only)..

Both methods have their pros and cons, and depending on the complexity of the mod being made, one method will be easier than the other.. (personally i pretty much always use the first method)

[mwieder]

Craig-

function revDebuggerValidGlobalNames

The IDE's built-in debugger already filters these out.

Or... you might want to try a different debugger... it's a plugin that completely replaces the built-in debugger stack

http://www.ahsoftware.net/PowerTools/Po ... DDemo.html

[dunbarx]

Mark.

The debugger preference to show or not show globals does not work. Is that what you meant?

Thierry's hack filters "$" and "gRev". This works fine for me.

I had hoped that with v5.x the problem would have been fixed, but it still has no effect. Of course, user globals are always shown.

You had contributed to the earlier thread:

if gREVDevelopment is false then
filter tGlobalsRaw without "grev*"
end if

Craig

[mwieder]

Ah. I misread your code - you wanted the $ environment globals filtered out as well. Yeah, PowerDebug does that. Been so long since I've had to rely on the built-in debugger that I forget these things.