How to prevent the text within the static control from getting clipped? - mfc

I am having a static control in which I am setting some text. When I am trying to set lengthy text in the static control the text is getting clipped.
Can anyone please let me know, how can I prevent the text from getting clipped.

The problem is that a static control always clips a word, that is longer than the width of the control. If you use the SS_LEFT style words are wrapped into the next line. So a higher control would help (I can read in the comments that this is possible).
But the Style must be SSLEFT and not SS_LEFTNOWRAP!
Another solution would be to use a Read Only Edit control without a border In this case you can scroll inside the edit control, because it is possible to give it the focus. Also you are able to use a vertical or horizontal scrollbar.
As long as you don't use WS_TABSTOP you will se no real difference between a read only edit control without a border and a static control. Except that the edit control can be activated with the mouse.

Make the static text control larger than the text you a putting in it. A window draws in its client and non-client space. It clips to its window.

If you're concerned about space on a dialog or form, or, language translation could be a possible issue, then you should consider using a CStatic tool tip. Using a tool tip would allow you to keep the current size for the control and provide a mechanism to display its full text. When the user mouses over the CStatic, a tool tip pops up to display the entire text. It's a compromise I've had to use to balance UI design with space on a dialog.

Related

View all content inside win32 window

I cannot see text/graphics at the very bottom of my win32 window, because it extends larger than my screen can fit. Even when I go in fullscreen mode, I cannot see the bottom text.
Is there a way for me to adjust my window or zoom-out of my window in order to see the stuff at the bottom? Or am I supposed to shrink all the contents inside the window?
I'm not exactly sure what I should do, but any guidance would be appreciated. Also I'm using C++.
Thanks.
You pretty much have two options:
Add a scrollbar (Adjust the window style or add a scrollbar control)
Stretch/shrink/resize the content

Getting dock area where an MFC CDockablePane was docked

I am working on a project that totally does not want to use the built-in window/dock state and position saving of MFC. This means that in my main frame, I set EnableLoadDockState(FALSE). As much as I love to change it back to TRUE, I can't.
I plan on getting the position where a CDockablePane was docked through onAfterDock() of my CDockablePane. My problem is I have no idea on how to get whether it was placed on the side, top or bottom, on another CDockablePane.
Is there a way to get this information?
Thanks!
I think there is a way to get it, but it's not going to be easy or pretty.
A you're trapping the OnAfterDock, I guess you're not interested in floating panes. So, for docked panes, you can use CDockablePane::GetDefaultPaneDivider (MSDN here), which returns - as MSDN says:
A valid CPaneDivider object if the dockable pane is docked to the main frame window, or NULL if the dockable pane is not docked or if it is floating.
The CPaneDivider object (MSDN here)
...divides two panes, divides two groups of panes, or separates a group of panes from the client area of the main frame window
The following partial screenshot says more:
So, for a regular pane divider, you can use the methods available on CPaneDivider to find the other pane, or another embedded CPaneDivider (so recursive interrogation necessary here) and check if the divider is horizontal or vertical etc.
For the other case described above, look at the CPaneContainerManager class, which (again as MSDN says)
...manages the storage and display of the current docking layout
From here, you can again drill down through the whole docking hierarchy that starts from your original docked pane.
If I were you, I would really really look again at using EnableLoadDockState or at least browse the MFC source code to see if there are any internal helper classes/functions that you can reuse.
I've just solved this issue. I can check CDockablePane's dwStyle (GetPaneStyle()) for CBRS_ALIGN_LEFT, CBRS_ALIGN_RIGHT, etc. No complex methods. Simple.

Making an MFC CTabCtrl not use the full control width for drawing tabs

We have a somewhat involved request for a change in our application, which is to make one of our tab controls only have access to part of the width of the control for the purposes of drawing the tabs, so that we can stick some additional status text in the remaining area on the side.
A picture would probably help:
As you can see, the tab control extends all the way to the right of the dialog, but we want a reserved area for "Total Inventory Cost", and we want to make sure that additional tabs (which are common) don't encroach onto that area.
I'm open to pretty much any means of implementing this, short of completely rewriting the application. We can switch tab controls if there's one out there that works better, or otherwise change the implementation of the tab setup within reason.
I would have thought that one could separately set the client area and the tab drawing rectangle areas separately, but that doesn't seem to be the case. Please correct me if I'm wrong.
Any help appreciated!
If I understand correctly, what you've got is this
Main window's client area:
-> tab ctrl occupying the enttire area
-> some other controls on top of tab control
What you could do is this
Main window's client area:
-> Small tab control at the bottom
-> All othe controls in main window's client area

Avoid Flickering on a dialog that moves its controls on resize

I have a popup dialog( CDialog ) that handles WM_CTLCOLOR message to color itself. It is having some controls (like bitmap buttons) that draws themselves using OwnerDraw. It is also having a control that displays an image with size that takes up to 70% of the dialog.
When user re-sizes the dialog, some of the controls in the dialog should be re-positioned (not re-sized). It also involves re-sizing of the image inside the dialog. As the re-sizing of image makes the whole process slow, individual re-positioning of the controls are causing a visual effect of flickering.
I need to get rid of these. One idea is to put the controls as the children of an intermediate dialog that is the child of the original popup dialog. So, when there is a re-size, I can re-position the dialog only instead of moving each controls individually. (Re-position happens only in one direction (x or y), so moving the intermediate dialog should be enough.
As it involves some coding effort, before going this way, I need answers to the following questions:
Will this work?
If yes, whats the complexity involved in this method?
Is there a better way?
Please help!
Simple fixes are:
creating the slow window last so that it doesn't hold up drawing of the simple controls
turning on the WS_EX_COMPOSITED style flag so Windows double-buffers the entire window, including its children. Beware of painting artifacts
turning off the WS_CLIPCHILDREN style flag so the holes are not so noticeable. Making the background white would accomplish the same
keeping the drawing of slow controls simple between WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE
using less controls, burning up an expensive window on a simple string or image is unnecessary
It will probably work, but you should try solutions that don't alter your control hierarchy before, because it has other subtle consequences (focus, tab order, message notifications, etc).
Try one or all of the following:
Use BeginDeferWindowPos/DeferWindowPos/EndDeferWindowPos functions to move the children.
Set the WS_CLIPCHILDREN style flag in the dialog.
Set the WS_EX_LAYERED extended style flag in the dialog.

Placing a image inside an CEdit control in Win32

I'm trying to achieve an effect where there's a visible logo inside an edit control and the logo becomes hidden when the user places the focus on the edit control.
What's the best way to approach this? Would it be better to place an image control on top of the edit control or paint the background of the edit control transparent and position the image control behind the edit control? Or possibly some other method?
The EDIT control has very broken paint behavior, you'll never get there by overriding the WM_PAINT message handler or using transparency. Yes, overlay it with a STATIC control that you hide when you see text being entered.