0
votes

I currently have an MFC SDI program that displays data in Open GL. I am trying to modify the program to display multiple data files at once using splitter windows. In other words, if there are four splitter windows, each with display a different file.

So far all the examples I have found only display one document in multiple views, but I need to display multiple documents at once.

I am starting to conclude that the problem may be because this is an SDI interface. I guess I originally thought that since I was using splitter windows that it would support multiple documents at once.

So my first question is, is the SDI interface the problem? Am I limited to just one file at a time?

If the answer is that I need to use MDI, then can I display the multiple documents in one MDI view using splitters, or do I have to still open multiple MDI windows?

Thank you

1
Sounds like you should restart your project with a MDI interface instead. :)Andrew Truckle
MDI is necessary for processing/viewing multiple documents (SDI creates only one doc object). There are basically two ways to implement this, MDI child windows (one for each document object), and tabbed views. Haven't ever seen an application using splitter windows to display multiple documents (one in each pane). It would look very non-standard, and if you undertake the task to implement the frame work yourself, you will have to resolve issues like how to split the client area if you have to display 3 or 4 documents, or the user opens another one - a lot of both spec and implementation work!Constantine Georgiou
One of our MDI apps utilizes a splitter window for different document/view types in each split. Very do-able (although not a default MDI app in that each document is a separate file, but ours is a single disk file that contains different "CDocument" derived classes).franji1
Thank you. After spending hours researching this it appears that splitter windows are intended to support multiple views of the same document and not for I am trying to do. One reason I went this route is this is what the customer requested, but I can probably convince them to go the MDI route instead.JRGlide
To ask this in a different way, what if I had an application that displayed multiple images at once, like in Lightroom? It displays multiple files at once, but it doesn't appear to be an MDI interface. So how would something like that be implemented? I considered going to a dialog based application with fixed window sizes, but that still doesn't solve the problem of opening multiple documents at once. Maybe another possibility is to do away with Doc/View and write my own controller. Each time the user opens a file I add it to a list and direct it to one of the windows.JRGlide

1 Answers

0
votes

I think creating multiple MDI-child windows should be very acceptable, as they are fully functional (they can be maximized, closed or tiled). You can also post a Window->Tile command, as soon as your app enters the idle state (yields); they will fully occupy the client area. You can even get deeper and provide some customizations to your CMDIChildWnd-derived class, like disabling closing, moving or resizing, or having a shorter or custom or no title bar (you may need to customize the non-client-area message processing). Also experiment with the WS_EX_TOOLWINDOW extended window style (not sure if this works well with MDI child windows though, and you will have to test it under at least Windows 8/10 and 7).

Another solution could be initially create an MDI app with tabbed views, and customize the window accommodating the tabs so that they are not... actually tabs, just simple non-overlapping child windows (you will have to arrange them on the client area yourself). This may be preferable if the view wnidows are of "fixed" size (either a set size or determined by the document data, eg image size) and should not be resizable (by the user). The MainFrame window should then be customized too, to display scroll-bars if the area required to display all views exceeds its client area. This is a lot of work though, as you will need to modify the window classes so as to provide a functionality MFC was not originally meant to support, and dig deeply into the MFC sources.