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
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.
This is an old question but for those who might want to do the same thing, MFC does support the scenario mentioned. From the Microsoft documentation:
MFC supports three common user interfaces requiring multiple views on the same document. These models are:
View objects of the same class, each in a separate MDI document frame window.
You might want to support creating a second frame window on a document. The user could choose a New Window command to open a second frame with a view of the same document and then use the two frames to view different portions of the document simultaneously. The framework supports the New Window command on the Window menu for MDI applications by duplicating the initial frame window and view attached to the document.
View objects of the same class in the same document frame window.
Splitter windows split the view space of a single document window into multiple separate views of the document. The framework creates multiple view objects from the same view class. For more information, see Splitter Windows.
View objects of different classes in a single frame window.
In this model, a variation of the splitter window, multiple views share a single frame window. The views are constructed from different classes, each view providing a different way to view the same document. For example, one view might show a word-processing document in normal mode while the other view shows it in outline mode. A splitter control allows the user to adjust the relative sizes of the views.
Microsoft MFC references
https://learn.microsoft.com/en-us/cpp/mfc/multiple-document-types-views-and-frame-windows?view=msvc-170
https://learn.microsoft.com/en-us/cpp/mfc/multiple-document-types-views-and-frame-windows?view=msvc-170#_core_splitter_windows
MFC samples
https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-samples?view=msvc-170#mfc-samples
MFC splitter sample
https://github.com/microsoft/VCSamples/tree/master/VC2010Samples/MFC/general/viewex
Related
I am trying to build a Level Editor for my engine and I wondered how I can achieve multiple viewport windows in one window, like in Blender, Cinema 4D or Unity, where you have your rendering viewport, scene hierarchy, properties window etc.
Does the win32 API have a function to create these viewport windows or do I have to create another instance with CreateWindowW with no title bar?
You could conceivably do this with a single window but this sort of thing is usually much easier achieved using a child window ((yes, created via CreateWindow(Ex)?) for each view and then a parent window that handles positioning those child windows (that is, a spliter type frame).
You may even end up with a window tree that is separate from the level view for a properties list etc.
It is simply much easier for the child windows to only need handle one thing (show an overhead level view, show a 3D projection etc) than to make one window class that does all of these.
There is no native notion of a "viewport" in Win32.
To support this kind of functionality at all, to create even a single viewport, you will need to know how to create a custom control. In Win32 "custom controls" are really just custom child windows. Say you have a custom child window class called "view" that handles rendering using a 3D library in its WM_PAINT handler, etc., then to support multiple viewports you fundamentally have two options:
Make "view" implement the functionality itself. Multiple viewports would not be separate Win32 windows. There would be one Win32 child control painted to look as though it was multiple windows. You would then need to handle all the internal UI interactions you offer the user 100% yourself. Dragging the view splitter bar, etc. The benefit would be that you could then make those interactions however you want, possibly totally nonstandard, and also performance while dragging and performing other interactions would probably be better than the alternative.
Use separate "view" child windows for each viewport. Handle UI interactions via other custom child controls, possibly, e.g. a view splitter control, etc.
Without more focus to the question that is about as much of an answer as can be given. The key thing to understand is that Win32 is a powerful but low-level API. If you are looking for an application framework that gives you a lot of functionality for free you should look somewhere else.
I am trying to place some overlay text over a wxPanel.
I have several panels with completely different Content but I want to place this overlay text over all of these panels in the top right Corner of the panel.
I am restricted to wxWidgets 2.8.12..
Do you see any way to achieve this behaviour?
Edit:
Here a bit more detailed Version of what I am trying to do:
I have a Layout that consists of e.g. 5 containers and each container can contain a module. A module can be either wxPanels that contain Plain text or Input controls or for example a OpenGL canvas or an Image or something else.
Because I have much content and it does not fit on a single page I want to make the modules inside a Container exchangeable. It would be also nice if the user is able to perform this action only by using its keyboard. E.g. if he presses the key "3" the content of the third container has to be switched.
To handle these shortcuts isn't a problem. However I need to signalize to the user the identifier / hotkey of the containers.
I could do this by placing a additional headline above each container, but I want to waste as little space as possible on the gui.
I also could draw directly to the modules content, but I would have to do this for every module and every module is designed in a different way (images, multi column, opengl, ...) and maybe even by different persons.
So I am looking for a simple solution to indicate the number of these containers that does not consume that much space.
Thanks for your help
You can use a wxWindowDC to draw anywhere on the window, even on child windows. However anything you draw will be painted over whenever the windows or controls repaint themselves. You can draw your overlay in an UpdateUI event handler to minimize this. I have used this approach with success on Windows with wxWidgets 2.8.12. Not sure if it works with OpenGL though.
If you look at the thumbnail images in Windows Explorer you'll notice that they have a drop shadow, is this effect associated with the ListView control or does Windows Explorer does some extra coding to accomplish this effect?
Edit:
So it turned out that Windows uses another control. So my question now is how can I add a drop shadow to the "normal" ListView.
For a standard list view, you may want to use a technique called custom draw (https://msdn.microsoft.com/en-us/library/windows/desktop/ff919569(v=vs.85).aspx).
Basically, you ask your list view not to draw its items, but instead send you some window messages for you to draw them yourself. This is a very flexible but also troublesome technique, because you need to handle many things (like whether an item is selected/disabled, font, color etc.)
The drop shadow you see in Windows Explorer is not publicly available for you to use. So you will have to custom-draw the items (NM_CUSTOMDRAW) by yourself.
Not sure if such effect is available in GDI/GDI+, but Direct2D does have one: https://learn.microsoft.com/en-us/windows/win32/direct2d/drop-shadow
I have a general question on how to develop an image viewer plugin with Firebreath. For that, I would like to incorporate a GUI framework, like wxwidget or Qt. The GUI would be used to to fire up some dialogs, adding a toolbar on top, or to open context menus with right clicking an image.
As far as I understand I have a hwnd handle and so I can draw onto a window. I also understand that I have various events I can react on, like mouse button clicks or keyboard strokes. But it fails me how I would add graphical menus, buttons, etc. I know I could use html around the window but that's not the route I like to take.
For instance, does it makes sense to render an user interface offline (in memory) onto an image and then keep somehow track of the state internally?
Has anyone done such thing? Or can anyone give me some insight on how to accomplish adding a user interface.
Assuming you only care about windows and assuming that you don't mind using a windowed plugin, which is the easiest (but no HTML elements can float over the plugin), it should be no different than creating a GUI in any other windows application.
You are given a window that shows up with the AttachedEvent; when DetachedEvent is fired you need to stop using the window. Many people create a child window inside that parent window and use that for all their actual real code which makes it a little easier to use one of those other abstractions, but that's basically all there is to it. I don't know specifically how you'd do it with QT or wxwidget but you'd create a child window of that HWND that you are given and have the abstraction do your thing for you.
As to whether or not it would be rendering things offscreen, etc, I have no idea; that would totally depend on the window system. There is no reason that I know of that you would need to do that, and most things just draw directly to the HWND, but there are a zillion different ways you could do it. It looks to me like what you really need is to understand how drawing in Windows actually works.
I hope that helps
I maintain an MFC (VC6) MDI application that uses Frame Windows as views for a document. There is only one document at a time but there are several MDI-Frames each with a different view of the document data.
Recently a request came up to be able to keep one of those frame windows on top of the others while being able to interact with the background windows.
One idea was to add a "pin-button" to the frame's title bar. During my research I found out that every implementation uses bitmaps instead of for example CButton objects. This starts to get ugly as soon as one uses window colors other than the default-grey let alone UI-Themes.
An option in the menu of the frame window (the thing that appears when left-clicking the window icon in the title bar) would be possible but I'm searching for something that is more obvious to the user.
What other possibilities to set this frame window's on-top state are there?
Update
I have decided to go for the solution suggested by Uli as that one works fine with the XP themes.
Unfortunately this directly lead me to my next question: How can I actually make the frame window stay on top?
Maybe this or this helps.
Uli