The Quirks With Multiple Edit Windows

Although probably not used very often, the New Edit Window command has been around for quite some time. I was able to track it down to Delphi 5, but I wouldn’t be surprised if it also existed in even older versions. With the prevalence of Multi-Monitor and Curved-Monitor setups more users may take advantage of this feature in the near future. In this post I am going to discuss some consequences of the interaction of separate edit windows with the docked IDE.

Creating a new edit window is pretty simple: Use the similar named menu entry in either the Views menu or the editor context menu. This gives you a new undocked edit window which allows editing several source files (even ones already open in other edit windows) as well as using the IDE designer after moving it to the selected edit window by clicking on the appropriate button in it’s design view. Working with two (or even more) edit windows is straightforward and allows to look at multiple source files simultaneously as well as typing in each while keeping the others visible. Especially typing in a source file while have another part of the same file in view can be pretty helpful in some cases. This feature undoubtedly offers a number of advantages.

It is no secret that I always have MMX Code Explorer installed and active in my Delphi IDE and make pretty much use of it. Unfortunately that turned out to be a bit clumsy when working with multiple edit windows.

I am used to having the explorer window docked into the edit window to the left keeping the eye and mouse moves between them as short as possible. Clicking somewhere in the editor automatically synchronizes the Explorer view to the entity at the cursor. The other way round, selecting an entity in the Explorer navigates the editor to the corresponding source section. Somehow I naively assumed that to be working the same with a separate edit window, I quickly learned reality actually looks different. While clicking in the editor still showed the expected behavior, selecting in the explorer was – well – a bit irritating: As soon as I clicked into the explorer view to select an entity of the unit I am currently working on in the second edit window, the explorer suddenly switched to the unit visible in the first edit window and my click fired on whatever entity of that unit was under the mouse cursor.

It dawned to me that this should have been to expected in the first place. The click into the Explorer moves the focus to the IDE window making the docked edit window, or better its currently visible edit view, the top one, which in turn triggers the change in the explorer. Damned!

Wait! The IDE should have the same problem with the Structure View. How does it handle this? A quick test showed: It doesn’t! A docked Structure View is as unusable with undocked edit windows as the MMX Explorer view is.

OK, as far as MMX is involved I am in a position to be able to do something about this. Fortunately, as there is no reference to follow, I would be pretty free to find a proper solution that I think is fitting best and follow my own needs. Hey, being the first one at least comes with a small chance to establish a standard.

After some arguing with myself I dropped the idea of a single Explorer instance in favor of separate instances for each edit view. This had the benefit of docking these instances next to the editor. I even opted for auto-docking the Explorer into the edit window. This solved the issues that would come with multiple floating explorers for visibly unrelated edit windows.

If anyone wants to give it a try: There is an MMX Code Explorer V16 Beta with this new feature.

Oh, before you ask: I am not going to make the Structure View support thisĀ  – at least not without having access to the Delphi sources…

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

The Art of Delphi Programming
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.