May 14th, 2007
It’s about time for some tips and tricks, and today’s post is all about using the debug window more effectively.
Evaluate!
In 4.0.3 and later, we’ve changed the debug window’s evaluate field to actually do what it says now: evaluate. Pretty clever (read: about time). So for example, where you used to type:
print( x )
You now type:
x
Think of all the saved keystrokes!
Hidden Commands!
During 4.0, I ended up adding some commands into the debug window for my own nefarious purposes. I just didn’t put it into the /help command. They are:
/mem Reports the memory used by JavaScript itself. Note that this is not the memory used by the application as a whole. It’s generally fairly small.
/gc Forces garbage collection to happen immediately, prints the final memory number. Again, this is the memory used by the JS engine, not by the entire application.
/tracethrow [on|off] Allows you to see what the file and line number is as an exception happens.
Secret Functions!
One of the most useful functions you can use is _dumpViews. You use it as such:
_dumpViews( windowVariable )
You’ll end up with a nicely formatted list of views in the specified window. This is helpful if you don’t understand why things aren’t visible, etc. I use this all the time to help debug engine oddities.
A sample output might look like:
Window 010AEB30 d:0 View (010AEE18): (0 0 100 200) d:0 z:-1 v:1 o:255 Image (01091910): (0 0 140 140) d:0 z:1 v:1 o:255 image001 src: Sun.png Image (01091AB0): (0 0 140 140) d:0 z:2 v:1 o:255 clipped src: Sun.png
In the output, there’s many abbreviated terms. ‘d’ means dirty, and is used internally for drawing. ‘z’ is the z-order of the view. ‘v’ means visible and should be 0 or 1. ‘o’ is the current opacity from 0 to 255.
That’s all for this time around. Hopefully the above items will help you debug your Widgets more effectively.
I figured out the evaluate function the other day by mistake. I thought I had just missed it all along. That little bit saves alot of time paying attention to closing brackets. And that dumpViews function will help immensely too.
Thank you for your nefariousness Ed!
Is there a Release Notes for 4.0.3 that lists all the changes?
Click the Information link up top and there’ll be a section for the version history.
Don’t know if this is the right place to post suggestions, but it would be convenient if there was a function that just automatically saved widget state. I’m thinking of something like MATLAB has, where you just say “save” or “save x, y, z” where x,y,z are any variables, and it automatically writes the specified variables (or all variables, if unspecified) to disk. The format of the saved file (by default called “matlab.mat”) is generally irrelevant to the programmer. All that matters is that to reload the variables, you just say “load”, and all the variables are back and accessible. This is very similar (seems to me) to the way widget Preferences are auto-saved; but to utilize Preference-based auto-save to store arbitrary variables, you need to define “invisible preferences” and such, which seems like a gigantic kludge (correct me if I’m wrong). I would expect to be able to say simply in the code something like “save myArray, myObj, etc.” and to have the widget automatically save these things somewhere on disk (in some sensible format). Then I would just say “load” (probably in the startup code), and I’d have my widget state back, with no need for invisible preferences or writing/reading text files, etc. Doesn’t this make sense? The functionality must already be there, because this is essentially what the Preferences auto-save does, no? Or am I missing something? Thanks.
Thanks for the new features but now if I enter “print(0);” to the debug window’s evaluate field, it prints:
0
undefined
and if I enter “t=3″ it prints 3. I’m not sure if it’s deliberate or a bug but I don’t think it should work that way since it prints unnecessary additional information.
Yes, it’s intentional. print() will output to the debug window, so you see the result of that. But the evaluation of print() results in undefined because the function has no result value. It’s a little odd, but it is correct.
Suggestion: functions with no return value shouldn’t cause any output on the debug window.
I find it very inconvenient to see that unnecessary information on the debug window. It used to be fine in previous versions. Can you at least add an option to disable the new evaluating method? I’ll really appreciate that.
The problem is that we don’t know what’s being evaluated. It’s just text to us (and the JS engine). We feed it in and get a result. And what you type can be quite complex, actually.
Just another “request for feature”: It would be nice if in the next version there would be better access to to “textArea” state, such as being able to acquire the left and right boundary indexes of user selections, current location of the cursor, etc. Plus use of CSS at the character level, of course… That’s what I want for Hanukkah. Thanks. By the way, how does Yahoo make money out of this whole thing? I don’t get it.
I very much like the “new” evaluate mode, which makes it consistent with my Widget Tester Widget.
Leave a Reply