Is there a simple way in C++ (and if yes, how to do it, preferably within Visual Studio VS2012) to set different font properties (size, type, bold, etc) for different elements of one dialog window (button, static text, title, etc)?
The font properties of a dialog window can be modified in its 'properties' dialog in VS2012, but they are then applied to all the window elements.
My need is to emphasize some information wrt other in the same window, e.g. to make it visually easier to differentiate labels from variable values, and static from modifiable variables.
Thanks for any help.
In a recent and well written article, John Morrison Leon presents his solution which precisely addresses this issue and more.
On top of enabling the wished for possibilities with formatting, it offers a whole new way to easily create and use dialog windows, purely C++ (Win32 without MFC or ATL/WPL, independent of the IDE, mapping at compile instead of run time).
The piece is a rather detailed tutorial, licensed under The Code Project Open License (CPOL). It contains all C++ source code (37.2kB zip) and examples (80+kB). It has won Best C++ Article of May 2015 (First Prize).
------------- some excerpts quoted from this (long) article -----------------------
An alternative approach in which dialogs are entirely specified as C++ code that requires neither IDE support to be written nor IDE generated resources to be executed. Powered by the C++ type system.
The fundamental difference with the approach presented here is that your code does all the work of creating the dialog rather than have Windows create a dialog from a dialog template resource that you then attach code to. There is no need for dialog or control ID's because there is no run-time mapping of code to a dialog template. Instead there is compile time mapping of each control to a C++ variable. Furthermore each of those variables has its own unique data type. Such rich typing is perhaps radical but it brings many benefits and is key to the design. It allows the C++language to resolve many issues at compile time through type resolution and this reduces and simplifies the code that you have to write. In practice this means that for every variable representing a control, say btnCancel, a unique data type will be generated with the same name prefixed by an underscore _btnCancel.As you will see, there are times when you will need to refer to a control by its data type _btnCancel rather than its variable name btnCancel.
The unfamiliarity of coding a layout instead of dragging and dropping it is dealt with in the next section and after that, most things are simpler, cleaner and more concise than you are probabaly used to.
There are some other innovations including:
•all control variables carry a dynamic text dynamic text buffer as_text through which the controls window text may be read and written, and which persists when the dialog is closed.
•support for non-windows controls that are simply painted onto the dialog and respond to mouse events. (examples are provided for some cases where this makes more sense).
•support for imposing aesthetic metrics (button sizes, spacing, colours, control styles etc.) at an application level on all dialogs hosted.
•replacement of the notion of 'Anchors' with Expand_X and Expand_Y styles for controls that can benefit from being enlarged if the dialog window is enlarged.
•some modest but effective streamlining of Win 32 programming with controls.
Related
I'm developing a C++ app in Visual Studio 2022 with a UI (UI library is wxWidgets). I'm trying to figure out how icons work. I gathered from researching that Windows expects a variety of different icons to be packaged with apps for the best UX (see Which icon sizes should my Windows application's icon include?). However I can't seem to find a way to get multiple icons taken into account.
My understanding so far is that all resource related things, including icons, are controlled by Resource.h and <projectName>.rc, both of which are initially provided by the VS template for a C++ App.
I've removed the provided icons (i.e the "normal" and "small" ones) and have instead imported many icons, one for each size, in the Resource View.
But regardless of that, always one icon seem to be used at a time.
Checking the contents of <projectName>.rc, I see the following:
I also expect the following, in Resource.h, to be relevant:
It seems that independently of the icon sizes, IDI_ICON1 is used. If it's 16x16, it's upscaled in context that requires it, if it's 256x256, it's downscaled (poorly, somehow ?) when required i.e in almost all contexts.
How should this be done ? Are there resources available on the matter I may have missed ?
You should embed all your ico files with different resolution into one ico file. The ico file is actually a container and can contain multiple images inside.
This question already has answers here:
Get text width in MFC
(4 answers)
Closed 8 years ago.
I am developing one Window based application, As it is window based desktop application I need to support multiple languages from Chinese to french and from Hindi(Indian) to Portuguese(Brazil) now thinks work great still there same size of text for display.But for following example,
If my one static control contain following text
Select Output Range |_Text Box__|
As i am developing it in English so size of static is considered according to English text size. Thinks work great.
Now same text i converted into Chinese view of above static control is like follow,
选择输出范围 |_Text Box__|
I am happy as size of Chinese is less than size of English but when i convert same text from English to french following is size of static control,
Sélectionnez Plage de sortie|_Text Box__|
My bad size of text is increased by some worlds as we have big text on less size text, View of text will clipped like following way,
Select Output Range |_Text Box__|
Sélectionnez Plage |_Text Box__|
In french size of text is increase ,So how to handled mismatch of text size pro-grammatically?
There are different ways to handle this problem. The answer depends on the way you handle the localisation in your code.
Note that some locals need the display to be inverted from left to right -> right to left (arabic...)
In this case you will have to handle cases where:
Select Output Range |_Text Box__|
must become:
|_Text Box__| <translated text into arabic or hebrew>
So you must be aware that translating a dialogbox is not just translating the labels. You have started noticing that because label lengthes are not the same.
If you choose to have a very simple localisation mecanism, like having a text file (containing the list of all labels) for each language, then you cannot do much more than trying to size your labels with a one-size-fits-all-languages. Dialogboxes won't look very nice in some languages. And you won't be able to use right-to-left languages. This is the quick and dirty way.
If you want to go further, the most common way is to have a resource file for each language. When your program is almost done, you have to duplicate the resource file. You have a copy for each language. You localize the whole dialogboxes, menus, etc. When you localize a dialogbox in French, you can make the label fields larger. And smaller for chinese. You can also change the dialogbox layout for arabic if you want.
Of course you have to build a version of your software for each language.
Your post has the MFC tag, so I suppose you might be interested in the MFC extension DLLs. This is the standard way for an MFC app to handle localisation. You create a DLL that only contains a resource file. If you support 10 languages, you duplicate and translate 10 resource files, and you create 10 extension DLLs. The MFC automatically load the right DLL depending on the current Windows locale. See for exemple a sample on CodeProject
I would not advise you to write some code that would automatically move and resize the controls when the dialogbox is created, because this is not as easy as it seems. Unless your app is quite simple.
I am not new in C++ but this is my first time developing a Win32 program. It has to be graphical and so I have been attempting to get user input using an input/dialog box with no success.
I have read this topic on MSDN and found it helpful, but I get an error about IDD_PASSWORD and IDE_PASSWORD not being defined. Declaring them in resource.h and giving arbitrary values (like 110, 111) yields no results. Other attempts I have tried to modify the auto-generated about box, which also yields no results after modification, I noticed that if i change the value of IDD_ABOUTBOX in resource.h from 103, this also does not work. I also tried using the .rc under Resource View, but still no results.
So I'd like to know if the resource box templates have predefined constant numbers that i have to use, if so where because I searched that too or if there is another way to obtain user input in a windowed application. I just want to obtain an integer, that's all.
There is nothing magic in the numbers assigned to resources. The numbers are what the code actually uses to identify the resources. Visual Studio just allows you to assign symbolic names to those numbers through the use of C macros (i.e., #define) to make your code easier to read. These values are all defined in the file resource.h by convention, and although you can modify that file manually, you usually should not do so—let the Visual Studio Resource Editor handle that for you.
The problem you're running into is that you actually have to create those resources first before the numbers will mean anything. When you create a new Win32 project, Visual Studio will automatically create an about box dialog and give it the symbolic ID IDD_ABOUTBOX. However, there is no such IDD_PASSWORD dialog created by default in a new project, and there isn't one built into Windows.
You can create this dialog yourself using the Dialog Editor (part of Visual Studio's Resource Editor), which is pretty easy to do as it allows you to drag controls around on the dialog where WYSIWYG. When you add a new dialog box to your project's resources, you will be given the option to name it anything you like. You can use IDD_PASSWORD if you want, or any other name. A numeric ID will be assigned automatically based on an algorithm; generally the lowest available number is used.
The article you linked to is assuming that you have already added a dialog to your project with the symbolic name IDD_PASSWORD (which is probably a mistake on the part of the author). All it shows you is how to display that dialog once it exists as part of your project's resources.
It's going to be somewhat difficult to learn Win32 programming just by reading the MSDN documentation. I strongly suggest getting a book that explains it more clearly and in a more logical order. The canonical text is Charles Petzold's Programming Windows, 5th Edition. Note that you will need to make sure you get the 5th edition, as the newer editions digress from their Win32 roots and start talking about completely unrelated things like C# and Silverlight.
If you absolutely must learn by trial-and-error and MSDN, start reading about dialog box resources here.
I'm trying to write to a custom Output Window Pane, but the only examples that I can find for writing to the output window automatically write to the Debug pane.
I've gotten as far as creating a custom pane with a VS add-in in C#, and writing text to it when VS2010 starts up. I'm working in a C++ project, and I'm just wondering how I can write to my custom pane from anywhere in code. I'd like to do it with as little overhead as possible, because I am working in a larger code base that I don't want to have to heavily modify.
Thanks
The Debug pane shows results of OutputDebugString calls (either direct, or by Debug.WriteLine / Trace.WriteLine) (it serves the same purpose as dbgview.exe from SysInternals). This is default behavior of the IDE. I think, that writing to custom pane may require implementing your own extension for Visual Studio.
As a workaround, you may use dbgview, define specific prefixes (as [MODULE-A]: , [MODULE-B]: etc.) and set filters to highlight occurences of specific words. Note, that dbgview will work properly only if you run your program without the IDE.
I am a .NET guy who is having to do some work on an MFC app. The app is a VS2008 MFC executable which I have converted to VS2010. The original developers did localisation by specifying the name of a .txt file with key value pairs in it on the applications command line. Installed shortcuts to the executable specify a different .txt file depending on which country the app is being installed in. This of course does not work if you just run the .exe directly. This seems like a weird way to do things to me.
I want to do this the propper MFC way, but I am having difficulty finding definitive answers on Google. My understanding is that the String Table in the .rc file should be used for this localisation? Is this the current best practice for MFC?
With respect to the String Table I have read that the practice is to create multiple string tables each for a different language. How do MFC applications choose which language to use? Is it based on the machines current language settings or can I control this (it may be that we want the language to be specified by the Wix .msi installer we are also building)?
I have also read that embedding all resource inside an MFC application has fallen out of favor and that now you should compile seperate resource .dlls? Is this is true ill investigate how to do it...
Finally, do I have to do something special to get MFC to support Unicode or is MFC Unicode by default?
Thanks
The idea is that all localizable items should be stored in resources. Standard UI objects such as menus and dialogs are automatically stored in there (resources) for you but items such as string literals (eg: error messages, messagebox prompts,...) should be pulled from source code to the string table. This short codeproject article of mine demonstrates how to easily pull strings from the string table in your code.
Note: You should have only one string table in your resource script (.rc).
From there on, you can translate your resources and create resource DLLs (aka satellite DLLs). The idea is that you keep a different copy of the .rc file(s) for each language. Each translation is compiled into a codeless DLL that acts as a container for the resources.
This other codeproject article of mine lets you easily load resource DLLs according to system settings or user preferences: The code looks among your resource DLLs which available language best matches user settings (based on user's UI language and regional settings). The code also lets you easily build a menu with all available languages. That way, your user can override the default choice.
DISCLAIMER: My ad follows. Feel free to skip :-)
Regarding the translation of resources, the management of translations and the creation of resource DLLs, you may want to check out appTranslator.
END OF AD :-)
Regarding Unicode, MFC ships with ANSI and Unicode versions of the code. It's up to you to choose if you want to build an ANSI or a Unicode app: Just make your pick in the first page of project settings. Of course, if you are startgin from scratch, you should definitely go Unicode. But if legacy reasons force you to stay ANSI/MBCS, don't worry to much: It won't prevent you from localizing your app.
Years ago when I had to work with multiple languages in MFC, we used separate resource DLLs. All you need do is make one call to switch which handle the resource functions would use and all was automatic from that point forward.
You need to do more than just change the strings. Dialogs in particular will have strings inside of them, and you may need to change the layout if those strings become too long after translation.