Rev Editor

• Now you can open a tab to another object while staying in your current tab.
• This allows you to keep working in the browser or on a script.
• Use command key (control on PCs) to open a tab without going to it.
• Works on Browser line items, links-to-handlers in code, and the scratchpad.
• Command+double-clicking a line item in Browser no longer edits name of line item.

• When Scratch Pad is unlocked, escape key locks it.

• If tRev thinks it's offline on startup, it now tries again.
• Scratch Pad contents now reliably preserved from session-to-session.
• When in zoom mode, controls in list can now be renamed.
• When in zoom mode and controls being renamed, escape key now exits renaming.

• Zoomed cards now show a fully functional list of controls.
• Control line items in list are draggable and names are editable.
• Zoomed cards also have the scratch pad.

• Controls in snaps can be dragged.
• Controls in snaps can be moved with arrows.
• Plain arrow = 1 pixel.
• Shift+arrow = on 10 pixel grid.
• Option+arrow = align to next control's side.

• First tab is always and only for the browser.
• New Tab menu item removed from File and Tab menus.

• Larger/smaller font size on view menu w shortcut.
• White on Black (aka Chalkboard) now on view menu w shortcut.

• Drag-n-drop in lists is more responsive, faster.
• Auto-scrolling during drag-n-drop in lists is faster, less quirky.
• Scrolling in all list fields and code field faster.
• Code displays faster.
• Browser columns populate faster (raw number of lines).

• tRev icon in Rev now remembers its location from session to session.
• Control counter no longer counts the controls in dataGrids.
• Inflated control counts kept script line counts from appearing in controls column.
• Alignment of all fields and buttons now perfecto!

You should click below to...

I used to debug in GLX2's and Rev's modal debuggers a lot. I was quite dependent upon them. In fact, I think I was using a debugger as part of my coding environment. My code got sloppier—I figured, "Hey, I'll catch any problems in the debugger." Time spent coding was, well surprisingly lengthy. It would wear me out. I didn't realize it at the time, but in retrospect, that's what I think was happening.

I'm speaking to you now more as a user of tRev than as its develper. I'd have to say that using tRev has changed my coding habits in general.

1. I spend much less time coding.
2. I spend about 80 to 90% less time debugging now as well.

Why is that?

I was somewhat mystified by this discovery, myself. Here's what I think has happened: my mind started working differently when I started using tRev. I really organize my code in the folders it provides in the handler lists, especially since I can drag and drop handlers wherever I like in the handler list's folders. I can actually find my handlers—even from older projects. The scratch pad containing links of frequently-worked handlers helps me find the handlers I'm working on, as do the links to handlers peppered through out my code, thanks to tRev.

The biggest thing I discovered about coding in RevTalk and xTalk is this: it's about the handlers.

How you get to them, how you organize them, how your regard them as good or bad—more important considerations than I ever thought. An example: the stats function in tRev even tells me my average handler size in a script. If the lines per handler is getting too big in a script, then I know I'm asking for rough sledding and wasting time. Coding in tRev is ALL about the handlers. When I realized this, I slapped my forehead and said: "It's the handlers, stupid!"

That's how I'd describe it. tRev has really made it easier and encouraged me by its example (you could say). It's easier to follow my own simple coding standards (naming vars with good names, not using nested functions, indexing repeats with var names, not "x", etc.). And the autocomplete feature really cut down on typos as well as the amount of typing.

So, firstly, my need to debug is less, because my code was getting better. Then, when I did debug in tRev (we call it "decoding"), one glance at the decoder and errors seemed to jump out at me. Most of the time I don't even step through the breakpoints.

That said, our decoder (a modeless debugger that appears after a script has run with an historical record stored in a database of breakpoints) still has some features coming. We are working on better support for multi-dimensional arrays and fixing some display anomalies. We're also adding support for breakpoints in repeat loops that let you walk through the iterations of variable content in a loop—after the code has run, of course.

The biggest advantage of the decoder: its design/architecture keeps it completely out of Rev's way. It cannot really crash Rev or tRev. It's like a good doctor that "does no harm."

People using tRev are challenged by the decoder because it is a completely different model. There is no debugger like it. But once you get to using it, and let it work on your head, you'll find some real rewards.

I am a very productive 61 year old coder and developer. You see here on this site just how often I update tRev with new features. I also do a significant amount of mentoring and project work for others. I also have a life with my family, community and friends outside of the technical world.

Bottom Line

You should click below to...

• Non-admin users can now use tRev without having to alter read/write Rev folder permissions.
• Sockets are being managed even more carefully to avoid conflict and to improve performance.
• Communication between Rev and tRev is now tighter and more stable.
• tRev no longer erroneously reports you are not connected to the internet.
• Errors indicating missing broker files and other components have been drastically reduced.