Archived Beta Discussions > SlickEdit 2013 v18 beta

MDI buffers and windows and tab groups, oh my

(1/2) > >>

jvert:
I want to love the new MDI architecture but I can't quite get it to work the way I am used to.

In the old architecture, I had Slick set up so that files share a window. Then I could v-split the window and set things up with different files in each window. (for example, .cpp source files in the left pane, .h header files in the right). I bound next-window to ctrl-TAB to quickly switch between windows, and I could use prev/next-buffer to cycle through the files in the current window.

With the new architecture, I had to change things so each file gets its own window (and therefore its own tab). Then I create a new vertical tab group. My problem is there is no prev/next-tab-group to switch back and forth between the left and right tab groups. prev/next buffer hops around between the two tab groups. I really want two different things - cycle through the tabs in a tab group, and cycle through the different tab groups. I don't see how to map these onto the existing commands.

Any suggestions?

Matthew:
If you really like using the "files share one window" mode (and a lot of folks do, including 50% of our dev team :-) ), then continue using it and dock the File Tabs tool window.

jvert:
Sure I can do that, but I was looking forward to some of the promised upcoming MDI features (floating tab groups, dragging tabs between groups, etc). I assume if I go back to the File Tabs, I wouldn't get those features.

I can probably crock up a macro that does what I want based on change_window.

jvert:
Turns out _MDINextDocumentWindow() has support for the behavior I want, I just needed to write a few macros to call it. Works for me, maybe you can convert the 50% of your dev team still using File Tabs :-)

_command void window_next() name_info(','VSARG2_READ_ONLY|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL|VSARG2_NOEXIT_SCROLL)
{
    wid=_MDINextDocumentWindow(p_window_id,'G',false);
    activate_window((int)wid);
    _set_focus();
}

_command void next_window_in_tabgroup() name_info(','VSARG2_READ_ONLY|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL|VSARG2_NOEXIT_SCROLL)
{
    wid=_MDINextDocumentWindow(p_window_id,'1',false);
    activate_window((int)wid);
    _set_focus();
}

_command void prev_window_in_tabgroup() name_info(','VSARG2_READ_ONLY|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL|VSARG2_NOEXIT_SCROLL)
{
    wid=_MDINextDocumentWindow(p_window_id,'2',false);
    activate_window((int)wid);
    _set_focus();
}

Clark:
I use "files share one window" mode like you. I suspect there will be two camps. Those who are like me that need a more pure emulation and those like you who will attempt to switch to the other window mode in order to have multiple tabs.

If you use "files share one window" mode like me, you still benefit from WAY better split window support and the ability to drag a window off to display on another monitor or wherever.

For those who try to switch modes, you're on your own a bit right now. You'll have to decide how you want to switch between files and windows. When we were designing the new MDI, I rolled some ideas around in my head but nothing worked well. One idea I had was to show tabs for all the buffers on every tab row. This would look too busy though, you would have too many tabs to show the path, and creating GUI tabs does have a slight speed cost (I'm a speed freak).

I may see what I can hack up for myself and see if I can deal with it. I'm very hooked on my key bindings and expectations of what they should do.

Navigation

[0] Message Index

[#] Next page