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.
Related
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
Okay, so, I have a C++ project I'm working on. I've created my own custom window using Cairo (I realize Cairo might not be the best for this application but it makes a lot of tasks that my GUI needs to do easier).
It controls the window size, minimizing and everything by itself, but when I create a borderless window to put it in, it still has an opaque background (my custom window has rounded borders).
How could I get the background to be transparent on at least the 3 most popular window systems? What are the platform-specific API functions that do this so that I can abstract it myself, or, is there a lightweight library that does this and will work with Cairo?
Is it possible to create a window with only Minimize and Close button (and preferably not re-sizable) in C++ and XLib?
On my Ubuntu I can see some of these type of windows (like the System Configuration window).
I am very new in the Linux+X11 world and I want to create a small window like this. How would this be done (not asking for code but for some references to the API components that would be of use or techniques that you know)?
You need to set _NET_WM_ACTION_MINIMIZE and _NET_WM_ACTION_RESIZE as the list of allowed actions for your window
I've been looking around for awhile about how to produce buttons using Direct2D and DirectWrite with no luck. I'm comfortable with shapes, text and that jazz. However, it suddenly occurred to me I might be looking about it in the wrong way.
Take the sentence:
you draw your controls and content for your app using the Direct2D and
DirectWrite APIs, handling all the input events directly.
I'm now thinking this means that instead of being able to quickly produce a fully functional button as I would using XAML. I would draw the button, manually check the location of the mouse on click, whether it's within the button boundaries and then handle the event? Similar method for hovering without the click.
Is this the kind of method required when using Direct2D and DirectWrite?
I haven't any experience with DirectX, but in OpenGL I build my buttons from scratch. Assuming you have animated sprites implemented, your buttons are essentially sprites that play certain animations in response to being clicked, hovered over, etc., and which you can register callbacks with. In my 2D engine, I have a class called UiButton, which inherits Sprite, and listens for various UI events. It gets more complicated when you want to handle keyboard navigation (arrow keys + enter to select) as you have to think about how the buttons are connected and which of them has focus at any given moment.
Here is my implementation for reference:
Headers: https://github.com/RobJinman/dodge/tree/master/Dodge/include/dodge/ui
Source: https://github.com/RobJinman/dodge/tree/master/Dodge/src/ui
If you're not prepared to roll your own, Googling "direct2d gui framework" seems to bring up some promising results.
Sorry I can't be of more help.
Yes, to draw a UI Button with Direct2D, you need to handle everything yourself, why? Direct2D is a 2D graphics API, not controls library. you need to draw the layout of your button, and handle the message of your button(such as click, mouse hover...), you lost lots of convenient and that's time-consuming, but the most important thing is: you can control it by yourself!
Direct2D is a graphics library. UI controls like, Text-selection, Textbox, and Buttons is not a part of it. However the benefits of using Direct2D and DirectWrite is we can implement our own UI controls, and having a full control of it.
Please also see: ID2D1Geometry::FillsContainsPoint() for hit-testing task.
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