Attached Thumbnails

MDI windows used to be the "big thing" a few years ago for this sort of thing but they're pretty much obsolete today. Usually you'd separate each viewport into its own window layer (or "panel" or "client area" or "frame" or whatever it's called in your case) and render there, and if you wanted to be able to resize viewports there is a "splitter" (or something) component that you can use which will allow the user to resize with the mouse. Even more work is needed if you want to make it modular (to move the viewports around, add and remove them, and even detach them as separate windows).

Or some frameworks have docking features which make this GUI stuff easier. What language/framework are you using to design the interface? It will be easier to answer you if you target your platform, this is too broad a question at the moment.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

but the splitter control itself is not the problem i.e. you can roll-your-own child window that paints a splitter bar on the screen pretty easily. The hard part is implementing the splitter semantics. This could be some work depending on how complex you want it to be, but basically it comes down to having multiple views or whatever in separate child windows that can be re-sized by dragging the splitter.

[win32] I'm finishing up working on a system for a project I'm working on (an engine editor). It's a system for docking windows which is cloned... I mean inspired... inspired by Visual Studio. See video and more info here: http://my.opera.com/adelamro/blog/win32-docking-systemI'm not sure if there is considerable commercial value in it (I'd appreciate input on that), but I think at least one form of it I will make available for free use.

[win32] I'm finishing up working on a system for a project I'm working on (an engine editor). It's a system for docking windows which is cloned... I mean inspired... inspired by Visual Studio. See video and more info here: http://my.opera.com/adelamro/blog/win32-docking-systemI'm not sure if there is considerable commercial value in it (I'd appreciate input on that), but I think at least one form of it I will make available for free use.

That's pretty nice looking ... Did you do the arrow controls -- the button thingies that determine if and where the child window is going to get docked -- as separate child windows or in some other way?

It's a single top-level popup custom control (window) with no borders, and has a GDI clipping region and transparency. The clipping region is recalculated when needed to shift the location of the central docking diamond as it's called. This control is the second major actor in this system after the dock host control.

It's a single top-level popup custom control (window) with no borders, and has a GDI clipping region and transparency. The clipping region is recalculated when needed to shift the location of the central docking diamond as it's called. This control is the second major actor in this system after the dock host control.

So the whole docking diamond is one non-rectangular window? When you say it has GDI clipping region do you mean you are setting its window region with SetWindowRgn or are you using newer APIs that I'm not familar with? i.e. "LayeredWindow" or whatever. (Basically my knowledge of Win32 GUI programming cuts off at about 1999)

However, in your case you need to implement more functionality in the window procedure. You need to paint the splitter in WM_PAINT and so forth. Generally if you've never done this before google "custom Win32 child window" and see what you find.

I guess it doesn't count as necro-ing if you necro your own thread. But reading back on that/this thread, you were asking about writing a game editor to Win32 and are now asking about MFC. I get the feeling that you are trying to write a game model editor "native" and don't want to have anything to do with anything that is not native. Which is fine, but in 2013 you also don't want to have anything to do with MFC. I was a big Win32 fan in the day, so I understand where you are coming from, but just to speed this all along, my advice is for you to get into QT. I think that QT is like the new Win32, in terms of GUI programming.Seriously if you want to get into GUI programming in C++, download QT Creator and test it out.