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)
Related
This is the first step to scroll two windows simulteneously, the second step is to find a way to apply that amount to the other program. But I really don't know where to start, all I see in from Google is about modifying the behavior of the scroll of the mouse, not the scrolling amount in one window. Advantages of using this instead of listening to the keys:
Scrolling will be seamless since the other program are scrolled in the background
Clicking on the scrollbar works
Different scrolling speeds don't affect the comparison
Moving lines in text editors won't scroll pages in PDF viewers
I can tell you what I would do, but it's not going to be fun...
Assuming the text is roughly evenly distributed (which it might not be between two languages like that, and two windows with different text sizes and widths, really consider this carefully before you do the work), then the goal is to force both scroll bars to be at the same percent relative to their whole. So what you need to do is write a function to determine what percent each scroll bar is at. I would screen capture both windows and crop out the important parts of the scroll bar like this:
Specifically the up and down buttons, the top of the scroll handle, the bottom of the scroll handle. Save them in their own files. Do it for both windows in case they draw their scroll bars a little differently.
Now the tricky part. Write a function that does the following: imagesearch for the top button within rightmost 25 pixels or of the specified window. Same for the bottom button. Same for the top of the handle. Same for the bottom of the handle. Use this to determine where your window is.
SetTitleMatchMode, 2 ; so it matches the end of the title
WinGetPos , X, Y, Width, Height, LibreOffice Writer ;exact substring of window name required
Use something like this to find the scroll bar parts.
CoordMode, Pixel , Screen ;so image search searches entire screen
barwidth = 25 ; make sure it's more than the bar is wide.
ImageSearch, TopButtonX, TopButtonY, X+Width-barwidth , Y, X+Width, Y+Height, TopButton.bmp ; no jpg, fuzzy edges make searches fail
Then do some math, something like:
TopButtonY := TopButtonY+TopButtonImageHeight ; because we only care about the position of the bottom of the button.
BottomHandleY := BottomHandleY+BottomHandleImageHeight ; because we only care about where the bottom of the handle is.
HandleHeight := TopHandleY - BottomHandleY ; how tall the scroll handle is
TotalHeight := TopButtonY - BottomButtonY - HandleHeight ;how tall the scroll field is
HandleOffset := TopHandleY - TopButtonY ;how far it is from the top
HandlePercent := HandleOffset / TotalHeight ; the part we care about. return this value
With a function like that, you can know how scrolled each window is. All that's left is to send the scroll commands. There's a few choices.
; ControlSend , Control, Keys, LibreOffice Writer
ControlSend , Control, {Pgdown}, LibreOffice Writer ; or {Pgup}
ControlSend , Control, {WheelUp}, LibreOffice Writer ; or {wheeldown}
ControlSend , Control, {Up}, LibreOffice Writer ; or {down}
If it lets you move the caret with up/down arrows while the window is inactive, that is probably the most precise option, even if it takes a bit longer. The fastest most precise way is to simulate a click drag also using control send. To use ControlSend you need to figure out which control you're working on. WindowSpy can help you with that.
So first: Find the scroll positions of both windows. Second determine which window is active. Third, nudge the inactive window in the correct direction. Repeat until they're within a certain tolerance range (otherwise it will bounce up and down endlessly).
I can't emphasize this enough, but please make sure that getting the scroll bars in approximately the same positions is sufficiently close before even attempting this. If it isn't, you will have wasted a lot of time fiddling with it. Keep in mind it will be less and less accurate the longer the text is.
If it is an option, I would definitely consider copying the contents of both windows into a program that gives you more access to the controls (or better one that is specialized for this purpose). If you had more access, you could use the paragraph breaks to line up the texts with far more precision.
If you really just want to see both texts side by side (and the paragraphs do line up), you could find a text editor that tells you information like this:
If autohotkey will let you read the text of that information, you can copy the PDF into autohotkey's memory (separated by line) and use autohotkey to show only the corresponding paragraph of the PDF as you move around in the editable document.
Hope something I said helps, good luck.
If I make button relatively small, it's caption turns to ellipsis.
How to turn off this feature?
Don't let the button go below it's preferred size, then it will never need to elide the text of the button label:
button.setMinSize(Button.USE_PREF_SIZE, Button.USE_PREF_SIZE);
I want to make very small button
You can use any of the below either separately or in combination:
Apply CSS to use a very small font in the button.
Make the label text for the button very short.
Use brian's answer which proposes explicitly setting the ellipse string to empty.
Use a small graphic icon instead of text.
You can use setMinSize as documented above in all cases (if you wish the button not to go below a preferred size truncating or eliding content).
In all cases, if you wish, you can also apply CSS to minimize the padding between the label and button the border.
From your previous comment (I want to use simple captions like "<" and ">"), I think option 2 (Make the label text for the button very short) is what you want.
You may also be interested in Joel's Designing for People Who Have Better Things To Do With Their Lives which would indicate, usability-wise that very small buttons are usually a pretty bad idea.
in your label/button you can use the textOverrun property to turn off ellipsis.
textOverrun.set(OverrunStyle.CLIP);
this is probably a bit late for you, so i am putting it here for lone wanderers digging up this question.
It puts ... because there's no room for the text. You can use bigger buttons or a smaller font but if you really want the dots gone use button.setEllipsisString(""); , but then you just get truncated text.
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
I am working with an edit control in a dialog--all MFC. The only style specified in the resource is ES_AUTOHSCROLL. The dialog comes up and displays correctly. The edit control also works and edits text correctly--up until a point. At that point, it stops displaying text completely. The edit control is just blank.
My first thought was to try and adjust the limits of the edit control by sending calling SetLimitText() on the edit control which just sends EM_SETLIMITTEXT. I set a big number which was 10x the previous limit, and verified by EM_GETLIMITTEXT that the number retrieved is equal to the number set. After that, I still have the problem and nothing is changed.
Next I tried trapping EN_MAXTEXT and EN_ERRSPACE. Neither one of those notifications was sent.
Lastly, I started trying a little different input, and if I entered a space or a period then I could get a few more characters displayed than if I entered a W. The font in the dialog is MS Shell Dlg which on my system maps to Microsoft Sans Serif. It's a proportional font, do different characters have different widths, so I was beginning to thing that maybe it was GDI related.
Next, I trapped EN_CHANGE, and when it is fired off, I went and created an IC for the display, selected the font into the IC from the edit control, and then called GetTextExtent() on the text in the edit control. The problems occur in display right around 32760 which is darn near the 16-bit signed integer limit.
So, I am thinking that my problem is GDI related in that the EDIT control cannot draw past that limit. I tried substituting a RICHEDIT2 control, but it displayed fewer characters before going blank.
The other weird thing is that if I keep on entering characters and call GetWindowText() on the edit control, all the characters will be returned. It is just that the edit control is blank.
Yeah, maybe I shouldn't be displaying that many characters, but it is what it is.
Does anybody have a better explanation, solution, or workaround?
I have a tab control and when there are too many itmes, I get tab item headers on multiple lines.
So it will be like
[TabItemAA1] [TabItemAA2]
[ TabItem3 ]
[TabItem4AAAAAAAAAAAAAAA]
I don't mind them stacking but when this happens, TabItem3's header stretchs to fit the width of tab control.
How can I prevent this or make the tab item content which is TextBlock to fit the extended width?
Thanks
That's kind of the way people expect to see it, though. The tab labels should be centered so you can easily read them. I assume you want to left or right justify instead. Changing the dominant UI paradigm is only a good idea if you're going to improve upon it.
It could get very messy, but you could nest another container inside the header and explicitly specify the size and alignment of the objects it contains.
For a different UI style where the tabs scroll horizontally instead of splitting into multiple lines, you could also check out this guy's article, titled "WPF Single Row Tab Control": http://rickdoes.net/post/2009/11/06/WPF-Single-Row-Tab-Control.aspx