I'm trying to adjust the caption of my main window to show as much of a file name as is possible to fit in the caption area. So, I'm looking to calculate the width of the area marked up here in the red rectangle:
Now, I would ideally like to have code that can use whatever system metrics are available and thereby avoid being caught out by all the various platform/theme/dpi variations that can exist.
How can this be done, if indeed it is even possible?
As andlabs said in the comments, the WM_GETTITLEBARINFOEX message can be used to obtain the required information.
This message can be sent to the window and the TITLEBARINFOEX struct is populated with the state and location of the titlebar and each of its buttons. From there it is a simple task to determine how much space is available for the caption.
First, call GetTitleBarInfo, passing a pointer to the TITLEBARINFO structure:
TITLEBARINFO tbi;
GetTitleBarInfo(hwnd, &tbi);
The width of the titlebar is tbi.rcTitlebar.right - tbi.rcTitlebar.left. But that includes the three buttons (Close, Minimize, and Maximize). The width of one button is GetSystemMetrics(SM_CXSIZE), so the width of the title bar minus the three buttons is
(tbi.rcTitlebar.right - tbi.rcTitlebar.left) - (3 * GetSystemMetrics(SM_CXSIZE))
Of course, the code works on all versions of Windows where the width of each of the 3 buttons is equal
Related
I'm writing a small application in Windows using win32(vc++) and I want to create a different view based on the position of the taskbar. How can I check the position of taskbar in code like any api?
You can use the SHAppBarMessage() function with the ABM_GETTASKBARPOS message.
The taskbar may be displayed on multiple displays so in general it's not possible to retrieve a single rect that defines it's position. It may occupy discontiguous space.
Use EnumDisplayMonitors to enumerate the attached displays. Then for each display use GetMonitorInfo to obtain bounding and work area rectangles for the display. If there's a difference, then that difference is (usually) due to the taskbar. Remember that the taskbar can appear on multiple displays.
I say usually because you might have applications with app bars that reduce the working area. But I'm guessing that what you really want to do is display your program so that it does not overlap with the taskbar, and if you want to avoid overlapping the taskbar then you'll likely want to avoid overlapping app bars too.
first off, I'm very new to using API's so please bear with me I'm on a steep learning curve !
I'm creating an application using Silverfrost Fortran FTN95.
I've been trying to initiate the opening of an initial Window within the program which uses the whole screen
useable area (the so-called WORKAREA in API parlance) but am having a problem.
Having used GET_WINDOW_LOCATION# API function within my Fortran code to obtain the dimensions and origin of the max possible area for
the window (without taskbar), I've then defined the 'origin' of the window to be at -n,-n where the border is n pixels thick and I've
increased the window dimensions by (2xn) in each direction so that the other 2 borders will be off-screen at top or under the taskbar at the bottom edge).
Anyway, I'm having difficulty obtaining exactly the same as produced via clicking the 'MAXimise button' on a window.
While the window produced itself seems to occupy the whole area available, when it appears the CAption appears right on the upper edge of the
CAption ba(i.e. not centre justified vertically).
Also, the MINimise, MAXimise and CLOSE buttons in top rh corner of window do not fill the whole depth of the CAption bar (they're about half the depth and indeed appear to be cut-off).
If I subsequently click the window 'MAXimise button' after initial window creation then the CAption and buttons re-align themselves correctly.
This is all illustrated in this image here:-
http://s1164.photobucket.com/user/john_pbucket/media/SilverfrostForumsImageFiles/MAXWIN-Summary_zpscajfx3vx.png.html
Note - I first created the full window with borders within the available screen area (this is the first example shown) where the window Border (8pix wide) is visible
The subsequent attempt to create the window as per the MAXimise button places the window at origin (-8,-8) and I increase the window dimensions by 16 (2xborder width) in each direction in order to get the borders off-screen, but thy're still there.
So, What series of Windows API commands should I be using exactly to get the window to open in a correctly maximised state, and are there any 'subtleties' of alignment and/or spacings I should be aware of which may be causing this problem?
I guess the question boils down to 'what sequence of API commands does the window MAXIMISE button execute ?' but I can't find an answer anywhere.
Maybe there are also some subtleties I need to know about with regard to any windows dimensions parameters which could be creating the anomaly ?
Any help/guidance would be appreciated. Thanks
I am using Visual Basic 6 (please don't laugh), and I would like to dynamically position a control, at runtime, in a position based upon the position of one of the "top level" menu items (such as "File", "Edit", "View").
Unfortunately, VB's Menu control (which is the type of control that these "File", "Edit", etc. things are) does not have any properties like "Top", "Left", "Height", or "Width".
I could just experiment, eyeballing it, and eventually arrive at numbers that I'll hardcode, but for various reasons I would prefer that the code actually figure out where the control should go.
I am thinking that perhaps there is some Windows API call that I can use to figure out the position of the Menu control?
Thanks in advance.
Edit: In case it matters, this is on an MDI form.
Edit #2:
OK, answering my own question:
You can get the position of each item on the main menu bar via the GetMenuBarInfo function, such as:
Dim mbi as MENUBARINFO
mbi.cbSize = LenB(mbi)
GetMenuBarInfo Me.hWnd, OBJID_MENU, lMenuNumber, mbi
Where "lMenuNumber" is 1 for the first (e.g. "File"), 2 for the second (e.g. "Edit"), etc.
That mbi struct has an rcBar member, which is the coordinates of the rectangle where that menu item is.
Unfortunately, it's in absolute coordinates relative to the screen, not relative to the MDI form. So, get the mbi the one you're interested in and of the first, and subtract.
Plus, the position as given in the mbi is in pixels, so convert as necessary to twips or whatever.
This is sort of doomed. Standard menus will vary in appearance and width with the version of Windows and the user's settings for UI fonts and such. For all we know Windows Next/8 may put them along the left side of the window!
If this information were meant to be used it would be available.
Perhaps if you could explain more about what you are trying to do with your UI we might have alternative suggestions.
OK, answering my own question:
You can get the position of each item on the main menu bar via the GetMenuBarInfo function, such as:
Dim mbi as MENUBARINFO
mbi.cbSize = LenB(mbi)
GetMenuBarInfo Me.hWnd, OBJID_MENU, lMenuNumber, mbi
Where "lMenuNumber" is 1 for the first (e.g. "File"), 2 for the second (e.g. "Edit"), etc.
That mbi struct has an rcBar member, which is the coordinates of the rectangle where that menu item is.
Unfortunately, it's in absolute coordinates relative to the screen, not relative to the MDI form. So, get the mbi the one you're interested in and of the first, and subtract.
Plus, the position as given in the mbi is in pixels, so convert as necessary to twips or whatever.
I have a window with child windows inside in it. The child windows take up about 1000 pixels of vertical space. However, our users don't always have 1000 pixels of vertical space available - they might have as little as 500 or 600 pixels.
I want to be able to display this window at a size of 500 pixels high, and have the user "scroll" up and down the window to see the full contents. The window should always be 500 pixels high, but the view within it should change.
Assume I can add a scroll bar somewhere so the user can choose which part of the window he wants to see. Windows will normally paint the window contents from height 0 to height 500; how do I tell it instead to "paint from height 250 to height 750", for example?
I know that I can set the viewport with functions like SetViewportOrgEx etc, but those functions require a device context - when do I call them if I want them to be "permanent"? Do I call them when I get the WM_PAINT message from windows? Or at some other time? And which functions from that family do I want to use?
Edit to add: I don't want to actually change the position of the child windows - they should stay at the same position, and the only thing that should change is the view into the window.
Thanks.
If (when you get messages about the scroll bars changing) you call ScrollWindowEx with the SW_SCROLLCHILDREN flag, the child windows should be told to scroll along with everything else. This ought to put them in the right position.
I have this Win32 user-drawn tab control that is created as:
CONTROL "Tab1",IDC_TAB_CONT,"SysTabControl32",TCS_BOTTOM |
TCS_OWNERDRAWFIXED | NOT WS_VISIBLE,0,14,185,88
I'd like for this control to have its tabs resize as never to have to see the "sliding arrows":
Now, pretty much everything about this control works as expected, except for that fact that it won't respond to TabCtrl_SetItemSize. Try as I may, the size I get for the tabs when I get to draw them (in the DRAWITEMSTRUCT passed to WM_DRAWITEM) is always the size that fits the longest caption in them and never the size I've set with TabCtrl_SetItemSize.
However, in the TabCtrl_SetItemSize documentation, it says that:
[TabCtrl_SetItemSize] sets the width and height of tabs in a
fixed-width or owner-drawn tab
control.
The only way I've managed to have a decent resizing is by setting a dummy string of the desired length in it by sending the control a TCM_SETITEM message, and writing the desired text in it at draw time. This is rather inconvenient and not a particularly nice hack.
Is there anybody who would know
Why TabCtrl_SetItemSize isn't working as expected? and/or
How to set the tab size properly?
Many thanks,
joce.
Setting TCS_OWNERDRAWFIXED style is not enough, you have also to add TCS_FIXEDWIDTH style.
The minimum size of a tab is at least icon width + 3 if icon is present.
If you have icons (imageList attached to tabControl), you might get those "sliding arrows" even with fixed width (if there is less space available than: number of tabs*(icon width+3)