Super editor zoom - proof of concept.

Posted by on in Blogs
David Clegg mentions in this post a new super secret, "super zoom" feature.  First of all the reason this "feature" isn't on by default is that it was implemented as a very quick hack to more or less simply be a proof of concept for the team to play with.  As such, it is riddled with problems that if you start using it you may encounter.  It is actually somewhat ironic that this comes up now because for the last couple of days I've been looking at this feature and how it should actually be implemented.

The way it is currently implemented is to simply hide/show the dock sites on the editor form.  This causes a couple of major issues.  First of all, when in the zoomed mode, you cannot easily get back to the other views without unzooming first (and you must to use the mouse for this operation).  Zoom the editor, then select View|Project Manager... nothing happens.  That is because the form is visible, but the site into which it is docked is not.  Try switching desktop states, by starting the debugger or manually from the desktop state dropdown... then it gets really interesting.  Again, it was only for some internal research and a proof of concept.

Similar to my post about adding auto-save and recovery of files to the IDE, I'll go through and outline the behavior I'd expect this feature to adhere to.  As I mentioned in the previous paragraph, this feature takes the somewhat naive approach of hiding and showing the dock sites.

The first modification to this code is to iterate through all the dock sites on the editor form and then go through all the docked clients within each side and hide them individually.  This will allow the docking system to properly track their state.  It will also allow you to still selectively re-show specific views.  Selecting View|Project Manager will now properly display the Project Manager view in its properly docked position.   The next change is how the "unzoom" is handled.  As there can be several views that are not visible when the view is zoomed, you want to make sure they remain hidden when unzoomed unless they were explicitly shown while zoomed.  Another requirement is that for all "unpinned" views, they should remain unpinned and accessible.  So there could still be a thin strip on the sides and bottom where the views can still pop up.  Finally, any large desktop changes, such as switching states, loading a new project with a saved desktop, etc should cancel the zoom state.

I'm sure the next question on everyone's mind is why wasn't this feature just finished and done right for RAD Studio?  The simple truth is that it fell too low on the priority list to make it into the product.  Things like this are always going to happen where good intentions just sometimes don't make it because of the reality of the schedule and other priorities.  Another side effect of this is that we can also get some direct feedback from the field as to the overall usefulness of the concept (irrespective of the implementation) before devoting actual resources to it.  By all means, follow the instructions from David and play with it.  Even given its limitations and shortcomings there is enough there to get the idea of what it would do.

Gold User, Rank: 83, Points: 11


  • Guest
    Lachlan Gemmell Friday, 21 September 2007

    On another hidden feature, sync edit params, I've just discovered in CRS2007 they don't work as well as they did in BDS2006. The parameters are filled in but sync edit is no triggered. Is this by design? I was actually quite surprised to find no official checkbox to turn this useful feature on/off.

  • Guest
    K A Friday, 21 September 2007


    What is the job description for chief scientist in CodeGear?

    I know you have implemented many awesome features into IDE (specially the Open Tools API) and this may be your base of continued interest in IDE, but I always thought that the chief scientist did the compiler/language stuff.

    How are technical areas distributed between teams in CodeGear?
    I'd always wanted to know the winner organization formula of the late Borland for creating something as sophisticated as Delphi :)

  • Guest
    Dan Barclay Friday, 21 September 2007

    One editor feature that would be VERY useful is split screen. I can't tell you how many times I've wanted to view a procedure and a call, or a procedure and a declaration in the same file. I used to have this In Another Environment and it was used a lot. If it's made its way into D2007 I haven't found it yet. Clues?

  • Guest
    Allen Bauer Friday, 21 September 2007

    K A,

    Why force me into a box ;-)? There are talented engineers already in charge of the implementation and design of the compiler. Make no mistake, I am certainly involved in the design of the language, as I'm also involved in the design and evolution of the RTL and VCL. The IDE happens to live at the crossroads of all the other technologies we do. The IDE is also how you, the developer, interact with these same things. I like to keep my hands dirty with those things I feel I can contribute to the most. I'm afraid I'd just be in the way if I were to start poking at the compiler... I think I'd be kindly asked to stop helping :-). I like to think my opinion matters, but I will defer many decisions to those that are most able to make them. Micro-manager, I am not.


  • Guest
    Allen Bauer Friday, 21 September 2007


    I agree. However there are a couple schools of thought on that one. There is the VS/Word approach, which just allows the one file to have two separate views, either horizontally or vertically. Then there is the "legacy" Borland/CodeGear technique that allows nearly unlimited nesting levels of splitting that forms a mosaic of editor panes. Each pane can also contain [I]any[/I] file. This doesn't work very well for the tabbed metaphor we're using.

    The former is far easier to implement and probably works "as people expect." Whereas the latter is a lesser known implementation and could be far more difficult to both implement and explain how to use.


  • Guest
    Uwe Raabe Friday, 21 September 2007

    Why not have something like the debug layout. Make two new layouts called "Zoom" and "SuperZoom" which can be selected from the layout combo as well as being triggered by a short cut. Thus the user can define what is visible in these layouts and you only have to implement the same logic as for the debug layouts (i.e. activate with a key code, restore the former when pressed again).

    Suggestion: let the user define hot keys for any layout.

    May be it requires to fix this error first:

    Report No: 47453 (RAID: 252136) Status: Open
    Dock Tabs appear at wrong position

  • Guest
    m. Th. Saturday, 22 September 2007

    1. For God's sake, Allen, the last thing that I wish is to see you as yet another so sad box-shaped armchair chief scientist! - ...but enough on this subject, let's go to the 2nd.

    2. Very nice Uwe's idea, but there are some small glitches, imho. In fact, in order to be a very streamlined UI, imho, the (Super)Zoom mode should disappear when is needed – ie. when the user switches to form designer, tries to find a program element from the structure pane (ugh! – not very functional, you know – if you want I can give you some hints, just drop me a note) and other actions which are code editor related but require some panes to be shown. Our approach – which we use from a small amount of years (~ 5), and for our small needs and for our user base it's very comfortable – is to put the entire area on which the zoom will occur (ie. everything underneath the toolbars) on a TTabSheet from a TPageControl with TabVisible := False. Ie. put the Code Editor and all the dock sites on, let's say, tshNormal where tshNormal.TabVisible:=False. Add another TTabSheet called (let's say) tshZoom with (again) tshZoom.TabVisible:=False, and, of course, set (by default) pcoMain.ActiveTabSheet:=tshNormal. When user will press the trigger for the Zoom action then in code you'll do pcoMain.ActiveTablSheet:=tshZoom and "your TCodeEditor".Parent:=tshZoom. Ideally, it's highly recommended to have "your TCodeEditor" on a panel and move on tshZoom /only/ the "your TCodeEditor", because otherwise it's possible to appear some side effects from resizing / realigning of some components / dock sites from tshNormal and, also, some flickering on restoring (ie. reverting from 'Zoom mode') – even if in your case, istm that it's highly unlikely to happen because "your TCodeEditor" has Align:=alClient. But in any case, is better, imho.
    With this approach we (and perhaps also you) obtain:

    - full flexibility of adding / changing / removing dock sites, panels, UI elements in the normal mode without touching the 'zoom engine' (because the normal mode are very loosely coupled to the zoom engine)

    - using for ex. TActionList.OnExecute, the IDE can very easily auto-switch to the normal mode if the action require this. For this you must, of course, group the actions in an auto-switch group (the most simplistic way: using the ol' .Tag prop.) eg.:

    procedure TfrmProducts.aliMainExecute(Action: TBasicAction; var Handled: Boolean);
    if (Action.Tag=ACTGROUP_AUTOSWITCH) and (pcoMain.ActivePage=tshZoom) then
    //switch back (set first the parent, and after the pcoMain.ActivePage)

    - the code is very clear, small and maintainable. And also, if you want to add other 'zoom modes' eg. for the 'history' pane, diagram pane of the must-to-be-released OPF ;-) aso. it's very easy to expand it.

    For the SuperZoom mode we use the C. Johnson's approach, using a fixed, borderless, no-title full-screen form on which we put our 'thing-to-be-zoomed' using the Parent property, and a code similar with the above one in the same event handler to do the auto-switch. It's very simple and effective, imho.

    Of course, an action with a (customizable !!! – of course this will be another neat feature for Tiburon: customizable keyboard layout, isn't it? ) key-combination will allow the manual switching between normal, zoom and SuperZoom modes.

    2.5 – The 'splitter'. A horizontal (or vertical) splitter it's a must in the code editor, imho. And if you think that's too simple for you, you can add some buttons on splitter for auto-expand & auto-collapse (something similar to ones found in JEDI's TjvNetscapeSplitter) and also, perhaps, it's ok to add some synchronisation options between the two panes, ie. when one sees the code underneath, to see above the method declaration in the context of the full class definition. The other, older Borland approach has the usability issues that you already mentioned, imho.

    Just my 2c and hth.

  • Guest
    Dan Barclay Sunday, 23 September 2007


    Implementation details aside, the IDE needs the single file split screen. Dunno how else to say that. What's more, it needs to be simple to use and not hidden in 15 layers of Alt-Ctrl-Shift-Key options. Put a splitter bar at the top, like has existed in VB IDE's for years. It's useful. Later, if you want to sync or something that's fine but don't let any of that get in the way of simple two view file editing. One view window, one edit window, switch between them.

    Simplify simplify simplify. While you're at it, have 'em make the block tab work off the tab if multiple lines are highlighted instead of Ctrl-Shift-I (I think that's what it is). Did I say simplify?

    Just an opinion.


  • Guest
    Allen Bauer Sunday, 23 September 2007


    I am certainly in favor of the single file split screen approach. In practice this is far more the common use case than the old-style BRIEF technique of "editor pane" hell...


  • Guest
    IanH Sunday, 23 September 2007


    I've missed a simple, single-file split view since I first started using Delphi, so I agree with everything Dan has said. Though I think he neglected to mention "simplify" ;-)


  • Guest
    Dan Barclay Monday, 24 September 2007

    I confess I'm guilty of overusing BRIEF editor panes myself but going to 1 is a deeper cut than we need .

    Simple usage is critical in all the IDE functions if you expect to attract new blood. You can make the more obscure stuff available for the zealots as more complex actions and they'll still use them.

    Never hide Simple. Put it out front where everybody can find it!

    I'm looking forward to seeing a baby splitter bar show up in the editor Real Soon Now.


  • Please login first in order for you to submit comments
  • Page :
  • 1

Check out more tips and tricks in this development video: