How to modify captions of windows created by visual studio project wizard - c++

I have craeted a Visual C++ project using studio 2010 wizard in which I have added things like FileView, ClassView, PropertiesWindow, OutputWindow etc, with the help of wizard. Now I am interested in changing the default captions/names of one of these items let's say FileView. The FileView has a resource string "IDS_FILE_VIEW" associated with it with value "File View" which is displayed as a caption of the FileView window. If I change the value of above mentioned string in the resources it does not change that caption and still shows "File View" as a caption. Could anyone suggest me that how can I customize captions and other features of such common windows created through studio wizards?
Thanks a lot.

You don't say, but I assume from the "IDS" that you are using the MFC libraries.
In MFC, the resource strings like IDS_FILE_VIEW are defined and used by the designer but it is quite possible to override them. Changing the IDS_FILE_VIEW resource's value will indeed change what is displayed when that resource is used, but you may have (inadvertently) prevented that resource being used where you expect.
I would check through your project files to see where this and related names appear and verify that there are no inconsistencies.
HtH
Ruth

Related

How to fix not working keybind in WebStorm IDE

I generally have a bunch of custom keybinds for WebStorm, but this one particularly does not work - Select opened file. I've bound it with different key combinations (see screenshots below), and also I've verified that it does not conflict with any MacOS keybinds (although even the ones that conflict actually do work).
Also when I hover the actual UI button, it shows different keybind for it (which also does not work).
So, essentially, I have to always click the UI button with the mouse. I'd like to be able to do so with the keybind. I'm not even sure how to troubleshoot this...
Does anyone else using WebStorm have this keybind working properly?
It's a known usability issue, IDEA-271054. The actual action you need assigning a shortcut to is Other | Select File in Project View:

Implementing a custom header bar for chromiumembedded

I have built the chromiumembedded cefsimple project successfully with visual studio. I need to know whether I could implement a custom header bar instead of below.
Eg: with a separate favicon and Title being set as a custom manner .. etc.
Your kind help is really appreciated.
Thank You !
If you are based on CefSimple, take a look at simple_handler_win.cpp. In SimpleHandler::OnTitleChange(), you can set the window title to what you want, instead of what CefSimple wants by changing the SetWindowText() call. This will appear shortly after launch, replacing the app name.
To change the app icons, just replace the icons in the projects cefsimple.rc.
If you want to change them dynamically, that will be a bit more work.

Is there visual representation in Visual Studio 2013 like in Netbeans?

I want to ask if there is in Visual studio 2013 a visual representation of my application like in NetBeans where i can add thing like containers or controls ex. Button or checkbox?
I know that one is Java and one is C++ (in my case).
Depending on the type of project that you create, you will be presented with different options to populate the UI. If you create a xaml or winforms project, it will present a toolbox on the left hand sidebar. These elements can be dragged onto your form and events can be added via the properties window on the right hand sidebar.
It's pretty easy to use and master within an hour or so. Don't be afraid to whip up a small test project to sample the different elements available.
[EDIT] - Once you have completed the creation of the win32 project, you'll need to add a new windows form. You do this as so:
right click on the solution explorer root (possibly called Win32Project1)
click the add item on the popup window
choose new item
select the Visual c++ node->UI
choose the Windows Form item and add
Now you will see the form on screen. Next, navigate to View Toolbox (CTRL+W, X). Now choose you control (start off in the All windows forms section). From here drag the desired control onto the form and party on it :). Thereafter, it's just a matter of adding code to the events (or creating class objects and referencing them via the events)

MFC Resource ID uniqueness

This is basically an extension of the question here.
I am working on an old MFC application where it seems the resource.h file has been manually edited and has gone messy. I see that there are conflicting IDs in there.
I just want to confirm if we can have two resources with the same ID of different type.
For example, I have something like
IDD_1 101
IDS_2 101
or
IDR_1 102
IDS_2 102
Basically, there are resources defined with the same ID, but of different types.
A comment to the original question says that Resources of the same type don't share identifiers. If that is true, is it also valid for the IDR_xxxxIDs?
I am asking because I am using the Resource ID Organiser which seems to think that all IDs must be unique.
Although it's not recommended it should work OK with different types. The API FindResource uses the ID and Type to identify the resource. The problems you're more likely to hit revolve around the way MFC uses the resource id to refer to another resource, e.g. the help text for a toolbar button. Those sort of bugs can be very time consuming so you might just want to bite the bullet now and re-number so your resource ids are unique.
I am asking because I am using the Resource ID Organiser which seems to think that all IDs must be unique.
I thought I would just add that there is an option in Resource ID Organiser that allows for conflicts between symbol types:
It is not documented in the help topic.
It depends on how the code uses the control. For example if the control is a button with a duplicate ID then there is no problem to use it. On the other hand, if the control is an entry of a menu then when the user click the related event finds the first available ID. I would think it is better to rearrange duplicate IDs.
Sounds like you need a resource renumbering tool. Here's a free & open source one:
https://sourceforge.net/projects/resrenum/
From the help file:
"ResRenum renumbers resource IDs in Visual Studio C++ projects. It's a console app, and it's intended to be integrated into the IDE as an external tool. It's compatible with any version of Visual Studio from MFC 6.0 onwards. ... The resources are sorted in alphabetical order within each resource type. The resource types are sorted in compliance with Windows rules."
Note that this method only works if your resource IDs adhere to the Microsoft conventions, e.g. dialog IDs should start with IDD_ and so forth, see TN020 ID Naming and Numbering Conventions:
https://msdn.microsoft.com/en-us/library/t2zechd4.aspx

Dropdown height bug in CComboBox (common controls 6.0)?

I've made a simple MFC application (Visual Studio 2008, dialog based) and added a CComboBox using the resource editor. I used the resource editor to specify the dropdown height. Then I added some code to add 100 texts to the combobox. If I run this simple application the dropdown height is ignored. If I disable the Microsoft.Windows.Common-Controls 6.0.0.0 style (disable the pragma that adds it to the manifest file) then everything works fine.
Has anyone noticed this behaviour (and knows a solution)? I've searched the web and msdn, but no luck so far.
The only solution I've found (thx to someone on the Microsoft MFC newsgroup) is to use the CBS_NOINTEGRALHEIGHT flag that states that the combobox must look to the exact size specified by the user rather then adjusting it automatically (the reason this is a patch is that the flag is normally intended to disable the feature where the dropheight is adjusted so that no partial items are rendered).
The difference is the "new" Common-Controls-6.0-style Combo-box, or the "original" old-style Combo-box (pre 6.0).
I guess Microsoft finally "fixed" the ComboBox control so it dynamically changes the height of the drop-down according to the number of items and the screen real-estate available, which is better than having a fixed height (IMHO).
Unfortunately I have no source for that, just wild guessing :)