I'm trying to achieve this here:
where if you hover over the border between the list view and the tab panel you get to increase the size of the top window whilst decreasing the size of the bottom window and vice versa but I'm at a total loss as to what flags need to be set to enable child window moving by the user.
It is not as easy as setting child window flags. The narrow stripe between the upper and lower child windows has to be a background window that implements a splitter window effect by handling mouse messages on the stripe. This link outlines the basics:
http://www.catch22.net/tuts/win32/splitter-windows
Related
I am trying to change the size of the UI Elements within a UWP Window on the change of the size of the window itself, such as clicking the edge of the window and dragging right. However, on increase of size, there seems to be Bounds set on the creation of the Window for the maximum size of the content, is there anyway to bypass this Bounds?
Try setting the UI Element's HorizontalAlignment and/or VerticalAlignment to "Stretch". Alternatively, if you want to scale it too, you may put the whole thing in a ViewBox. There are really quite a few options to achieve what you want.
So i have a GUI with a toplevel GtkWindow that has alot of boxes and windows beneath it. See image below
the problem is when a user resizes window1 (downwards) , the bottom element, i.e statusbar2 only enlarges and fills up the rest of the available area.
The notion of a status bar is that it should be always the same size, like 80 px of height. What I want to do is that when a user resizes the window, the internal components stay the same relative height and width. Atleast the status bar. So when i drag down to enlarge, the box3 item should only enlarge. The statusbar2 should "hook" onto the bottom edge of the window and stay the same size.
This must be doable surely?
If you need the glade file, I might be able to upload it
Any help is appreciated!
Regards
You'll want to set the status bar's vexpand property to False, and set the vexpand property to True of whatever widget(s) you would like to absorb the extra space.
I have main window of my app divided into three areas (top, content, bottom). Some of controls are docked to bottom or to top and rest of controls are placed in 'content' area between top and bottom area.
If the total height of controls in 'content' area is greater than available space, some controls overlay controls docked to bottom. Similar problem occurs when I scroll up 'content' area. Some controls overlay controls docked to top.
How to limit area, where a child control(window) can be drawn? I found function SetWindowRgn(), but I'm not sure it's is the correct way, how to limit child window drawing area.
thx
The best way is to make your controls children of another child window with the WS_CLIPCHILDREN style set on it. That also makes it easy if you want to allow those separate areas to scroll independently of each other - all you have to do is reposition the child controls in response to the scroll offsets and they'll automatically be clipped to the parent window's borders.
When the OS X dock is shown, it "reserves" some screen area and prevents maximized windows from going behind the dock when maximized. How do I make my own Cocoa application do the same?
A window's "maximizable area" is based on the screen's visibleFrame.
[[NSScreen mainScreen] visibleFrame]
The returned rectangle is always based on the current user-interface settings and does not include the area currently occupied by the dock and menu bar.
Because it is based on the current user -interface settings, the returned rectangle can change between calls and should not be cached.
The rectangle defining the portion of the screen in which it is currently safe to draw your application content.
There is no mention of being able to adjust this visibleFrame rectangle, so I do not think you will have any success influencing the "global" Zoom size.
However, if you only want to adjust the Zoomed size of your app's window, return a smaller rectangle in the NSWindowDelegate method windowWillUseStandardFrame:defaultFrame:.
The standard frame for a window should supply the size and location that are “best” for the type of information shown in the window, taking into account the available display or displays. For example, the best width for a window that displays a word-processing document is the width of a page or the width of the display, whichever is smaller. The best height can be determined similarly. On return from this method, the zoom: method modifies the returned standard frame, if necessary, to fit on the current screen.
This will allow you to take into account a "docked sidebar" when Zooming your app's windows. Other apps will be resized on top of the docked sidebar.
Each time I create any type of cocoa project (document-based, with core-data and/or spotlight importer) and open MainMenu.xib, I get a warning sign in bottom right object palette window corner saying that window is out of screen bounds. Why is this so? Any remedy?
I get a warning sign in bottom right object palette window corner saying that window is out of screen bounds. Why is this so?
Because the window falls at least partially outside the screen bounds.
Any remedy?
Put it completely within the screen bounds. Select the window and use the Content Size & Position section of the Size (⌘3) inspector to move it.
Simply dragging the window by its title bar will not help, since that position is only for display in IB; it doesn't affect the window that will appear in your app, which is what the warning is about. You need to use the Size inspector.
I once had a similar problem when I had a second monitor connected to my MBP.
When the second monitor was set to a low resolution (I think it was 1024x768), Interface Builder came up with that particular warning. (Although the window did fit between the main menu and the Dock).