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.
Related
I am trying to recreate a Visual C++ Solution that had about 30 projects so that the general organization will be cleaner.
The original "solution" was in fact a Visual C++ 6 workspace from the turn of the century, migrated into VS 2017.
Some of the projects will be close to being clones of the old ones.
When I try to create a project, I am asked what Application Type it must be:
Single Document/Multiple document/Dialog based or Multiple top level documents.
I thought I could guess this by looking at the property pages of the existing documents, but I can't seem to find it. Or am I likely to be going in the wrong direction?
As far as I'm concerned, we couldn't guess this by looking at the property pages of the existing documents. I suggest that you could check MainFrm.cpp in the project source file to distinguish the project from a single document / multiple documents / dialog based or multiple top-level documents.
A multiple documents:the document's frame window can hold multiple child windows.
IMPLEMENT_DYNAMIC(CMainFrame, CMDIFrameWndEx)
A single document:the document's frame window can hold only one document.
IMPLEMENT_DYNCREATE(CMainFrame, CFrameWndEx)
dialog based: There is no MainFrm.cpp in the source file.
multiple top-level documents:Creates a multiple top-level architecture for your application, where a view class is based on CView.
IMPLEMENT_DYNCREATE(CMainFrame, CFrameWndEx)
clicks New Frame on the File menu:
For more details, I suggest you could refer to the Application Type, MFC Application Wizard
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.
I'm new to visual studios and I just created this very short calculator and I want to put it on mediafire for people to download but I wanted to change the icon..
I've heard that you select your app in solution explorer and Project>Properties
But my properties menu seems different.
It saids calculator property pages.
It doesnt have the tabs like ~Publish~ or ~Applications~ where people said you change your icon.
My properties is like this:
Configuration: Active(Debug)
and some other stuff below it some complicated stuff(to me)
Why doesnt mine have what other people have? I just want to share my first ever app with a custom icon. Help please, will appreciate it.
Create a text file, rename it res.rc, edit it to contain the line:
201 ICON "myicon.ico"
Add that file to your project. The file myicon.ico must exists.
Note: This is a bit hacky, the numerical vaulues should preferably be defined in a header.
You might be confused because Visual Studio supports different languages, and its UI is not consistent across those languages. Since you tagged it C++, the "old" rules apply. An application icon is a so-called resource.
You have to provide an .ico file, and reference it in a .rc file. The resource compiler (RC) compiles it into a .res file, and the linker then adds it to the EXE.
In C++, if you open the form in designer view, the properties window has an icon property that will allow you to browse for the icon of your choice.
Just for reference, i spent two hours trying to change it without any success until i resized the icon, it should be 32x32 and another one for small icon -not sure if its necessary though- with 16x16.
visual studio creates two icons when create the project , one is called small.ico and one is name yourexe.ico, just replace those and make sure to have correct sizes.
Background: Adobe released their first open source fonts to the GitHub. Repos consist of many files with different syntax, some of them are binary. See e.g. https://github.com/adobe/source-sans-pro
In the corresponding README file, build process is outlined like this:
> Key to building OTF or TTF fonts is makeotf, which is part of the AFDKO toolset.
> In this repository, all necessary files are in place for building the OTF and TTF fonts.
It works, but doesn't contribute to my understanding of the font creation process. I've found specs of some of the formats, but very little about what they do. A good HOWTO would help a lot.
And the main question is, I have glyphs in SVG (or any other vector) format and necessary metrics for each glyph. Let's also say that kerning is a non-issue for now, to keep things simple.
How do I build an OTF (or TTF) font file automatically with those?
I'm comfortable with both programming and reading the f. manuals, just don't know where to begin.
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.