We are using MFC static control in a dialog box to display some content to user. Both static control and dialog box are defined in a resource file (.rc) as LTEXT and DIALOG. Problem is if content is more than 256 character, it gets truncated. Does anyone know how can this limit be increased. The control and dialog box are old style.
You can vote for this problem here. Don't expect miracles, the resource compiler is neolithic. You'll have to work around it by using more than one static control or setting the text at runtime in the WM_INITDIALOG message handler. Don't overestimate the user's patience.
Static controls display text but have no user interaction; They don't have scroll bars, and truncate text to fit the control's bounds. If your problem is that the text fills the control and is truncated, consider switching to a read-only edit control.
If however the control is only accepting 256 characters even though there is room for more, I'm not sure why that would be. MSDN doesn't mention a limit to the size of the control's text.
In my understanding the compiler seems to have limitation with the in-lined strings in the compilable modules. Why don't you mind creating a string table if you're using such large text for a caption? For static controls there are no such limitations with 256K characters.
Related
Is it possible to add custom controls to a console window? You can use GetConsoleWindow() to get the window's handle, and then add your own menu items or consume all its events. I can't find any examples of people adding extra controls though.
I am developing a small, high performance serial terminal app. It is a console application - RichTextBox is too slow and has issues that make it unsuitable for VT100 terminal emulation.
I want to add some little graphics to show the state of the serial control lines (RTS/CTS/DTR/RI etc.) and perhaps a capture on/off toggle button. Ideally I'd like to add them to the window title bar. Bitmaps are all that are required.
After lots of research I found that it isn't easy, or even possible really.
You can add controls to the window with CreateWindow(), but of course only in the client area which is taken up entirely by the console text box. However, you can at least create floating controls that way, which hover over the text to provide status info etc.
You can put controls in the window borders but only with some hacking on XP or a new API that was introduced with Vista. The problem with this API is that it requires you to draw your own program icon and title text, and the console window doesn't seem to cope with it very well.
You can't add your own menu items because the console window doesn't pass the messages.
In the end I used the function keys for everything and gave a status indication by changing the console window icon.
using a windows EDIT control with ES_NUMBER style and with an accompanying UPDOWN control, the default number written to the EDIT control uses a comma in the thousands place. Is there any way to turn off this behavior?
I tried intercepting a notification from the UPDOWN control and immediately overwriting the text but it looks like either the notification isn't being detected or I'm overwriting the text just before it writes the new value.
Add the UDS_NOTHOUSANDS style to the spin button control.
I have a simple mfc project built on a CDialog. I also have a class I call CDroppable that inherits from CStatic with an added OnDropFiles()-function.
What I do is I add a normal CStatic to my dialog, add a control variable, then change the control variable in the .h-file of the dialog to be a CDroppable instead of CStatic (I think this is fairly standard). I also modify the Accept Files behavior to true for the CStatic.
In my opinion this should mean that if I drag a file over the dialog anywhere outside the accepting window I should get the "invalid" icon, and inside the accepting window I should be able to drop it. That is at least how it worked in VS2005.
However now in VS2010 I can't get it to work. The entire application displays the invalid drag icon. I can set Accept Files on the dialog itself and it will accept files correctly, but I don't want the entire dialog to accept files, I want CDroppable to accept files.
Is it some obvious thing I have missed to activate? Some setting that needs to be changed?
MFC, making simple things impossible (tm)
Actually I found what was wrong.
I had a group box around the droppable area to indicate where it was. This was obviously a stupid idea as even though I had set it to transparent which I assumed would be enough, it still was in the way of the droppable area. I had to set it to disabled and after that it magically worked.
Sorry to take your time.
We have an application that uses various system tray icons to communicate with users. Different icons indicate different internal states of the (otherwise windowless) application. We implemented our system tray stuff using code from this Code Guru project (the MFC version; this is not a new application by any means), and until recently, it has worked fine. However, recently we have tried to add another icon and have run into trouble.
Here's how it's supposed to work:
We have one main icon (call it 'A') that indicates that the application is running.
If a particular event occurs, we display icon 'B', over which the user can hover their mouse to get a tooltip with status regarding that event.
If a (recently added, internal, threaded) procedure starts, we display icon 'C', and again, the user can hover over that to see a tooltip that indicates the progress of that activity.
What's actually happening: if icon 'B' is visible when we (try to) display icon 'C', then icon 'B' either disappears entirely, never to return, or it stays there and icon 'C' never shows up, but the tooltip for icon 'B' is changed to what icon 'C' should have.
I've simplified the scenario a bit; we actually have a few other icons, but they're rarely used. However, we have never had any trouble displaying multiple icons until we added icon 'C' in the last couple of weeks.
Any ideas? Happy to clarify anything I haven't explained well.
You need to use a different uID for each icon. The documentation says:
The application-defined identifier of the taskbar icon. The Shell uses either (hWnd plus uID) or guidItem to identify which icon to operate on when Shell_NotifyIcon is invoked. You can have multiple icons associated with a single hWnd by assigning each a different uID. If guidItem is specified, uID is ignored.
In other words you need to pick a value for uID. This is how the shell knows which icon you are referring to each time you call Shell_NotifyIcon(). Clearly you must use a different value for each icon. So, use 0 for icon A, 1 for icon B etc.
I was wondering how can I read text of a control that doesn't have an HWND. For instance, the print dialog in office 2007 doesn't have HWND on all of its controls (only a few).
Is there anyway to get the text from these controls?
I believe they're simply drawn on the window and react using HITTEST, but I'm not sure, so I'm asking you guys :-).
Thanks for your help!
Generally, there is no guaranteed way to do that. However, chances are you can get the text (and other info about the controls) using the IAccessible interface. Most Microsoft products implement this interface on most of the UI elements: this is how screen readers for disabled people work
For a generic windowless control, all you can assume is that the text exists only as pixels on the screen, so the only way to read it is with OCR.
If you can learn more information about the specific controls you want to inspect, then you might learn that the windowless control has a parent window that handles messages on its behalf, or that the control has a COM object you can manipulate, or that the control honors the Windows accessibility API. If you don't know anything else about the control, then all you have are the pixels.