I wanted to ask about winApi 32 custom icons creation. When I define icon in recource.h:
#define IDI_MYICON 1
What does that number, in this case 1 mean?
And what about IDI is it just a standard or it actually means something?
1 is the value, IDI_MYICON is just a placeholder for the 1
IDI is an prefix and stands for An Icon or bitmap resource
see this list
Normaly ResourceID's get assigned automaticly by Visual Studio (or other IDE).
So you could use IDI_MYICON instead of using the 1 in your code.
Icons are stored in the resource section of the PE file when it is built. The "1" is the resource identifier for that icon. It doesn't have to be "1" but each icon must have a unique identifier. It's just easier to start at 1 and go up.
IDI is a Microsoft convention to identify an Icon resource. You could actually name it anything you want but sticking with convention will lead to less confusion.
Related
I have a simple Win32 project generated by VS 2012. In the resource.h file, I saw this:
#ifndef IDC_STATIC
#define IDC_STATIC -1
#endif
I found it is been referenced in a couple places in the resource.rc file. But I could not understand what it means. Neither did I find reference about it online. Any idea?
When creating child controls by calling CreateWindowEx, you have to assign a control ID (through the overloaded hMenu parameter). The control ID can later be used to refer to a control, without having to store the dynamically created HWND (e.g. when calling GetDlgItem or GetDlgItemInt).
Some controls rarely need to be identified in code. A prominent example is the Static Control1, that, if defined in a resource script, usually does not need to be referenced in code. You (or the dialog manager) still need to pass a control ID when creating the control, even though you don't use it later on. For those controls you can pass the IDC_STATIC control ID, that is defined in a wizard-generated Resource.h file2.
1 Other examples include the Icon Control (a static control with the SS_ICON style), the Line Control (a static control with the SS_ETCHEDHORZ and SS_SUNKEN styles), or the GroupBox Control.
2 This is not a convention of the Windows API3. It is strictly a decision made by user code. You could use another ID value, or not define IDC_STATIC at all if you want, and use an integer literal in the LTEXT control statement instead: LTEXT "Filename", -1, 10, 10, 100, 100
3 Granted, the SDK header winres.h does define the preprocessor symbol IDC_STATIC as (-1), so if you do define it in your code, make sure to assign the same value to avoid any confusion.
In the three MSDN articles linked at the bottom of this post, the pre-processor macro XM_CXSMICON is mentioned. In context, it is supposed to be the index of the system metric that gives the width of a small icon in the notification tray or on the balloon-popup of such an icon.
Here is a quote, verbatim:
NIIF_LARGE_ICON (0x00000010)
0x00000010. Windows Vista and later. The large version of the icon should be used as the icon in the notification balloon. This corresponds to the icon with dimensions SM_CXICON x SM_CYICON. If this flag is not set, the icon with dimensions XM_CXSMICON x SM_CYSMICON is used.
The other three macros from that quote, SM_CXICON, SM_CYICON and SM_CYSMICON, are all defined in user32.h as expected but no header file in the Windows API defines XM_CXSMICON. Searching the MSDN only returns the hits linked at the end of this post, all of which are related to notify-icons.
With this evidence, I conclude that this is an error and the macro is actually SM_CXSMICON which is defined on the line above SM_CYSMICON in user32.h.
Can anyone confirm this guess or provide further information?
The three MSDN articles in question:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773352(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774428(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ee453691(v=vs.85).aspx
Yes, that is a typo. It should read SM_CXSMICON x SM_CYSMICON.
I'm working on a Windows app that needs to run on XP, Vista, 7, and 8. I'm trying to set the application icon, and it works, using DI_ICON1 as the tag in my RC file:
DI_ICON1 ICON DISCARDABLE "myapp.ico"
Using IDI_ICON1 didn't seem to do the right thing here.
However, I also create a second window (also at the root level, ie not a child of my app's main window) and the ALT-TAB icon for that second window wasn't showing up correctly; it was just the default, generic app icon. Adding a second line to the RC now made the ALT-TAB icon work:
IDI_ICON1 ICON DISCARDABLE "myapp.ico"
so with both lines everything works. But I don't know why or how or wtf these identifiers even mean. So what are they, where are they defined, and by what magic do they work?
IDI_ICON1 is just a unique name identifying the resource. You can give it any name as long as it is unique. The development environment should generate a Resource.h file that uses a #define preprocessor directive to assign it a 16-bit unsigned integer unique identifier.
See:
https://learn.microsoft.com/en-us/windows/win32/menurc/icon-resource
https://learn.microsoft.com/en-us/cpp/windows/resource-files-visual-studio?view=msvc-170
IDI_ICON1 is probably just a convention that someone came up with, where IDI means "ID Icon", and 1 is because it is the first icon being defined. So, if you were defining another icon you'd identify it with IDI_ICON2. If you were defining a bitmap resource, you would identify it with IDB_BITMAP1.
DISCARDEABLE is only relevant for 16-bit Windows. See: https://learn.microsoft.com/en-us/windows/win32/menurc/common-resource-attributes
How can I change the order of the entries in the context menu?(e.g. for Directories) I need to know how Windows determines the order when showing that so I can control it. For example I want to place my custom action at the end of the context menu list
Thank in advance!
My Google-fu led me to this:
So the sorting is based on the following elements in decision order:
Key priority (eg, txtfile, *, AFSO)
Registry Enumeration order of shellex\contextmenuhandlers with a special case for static verbs always being first
IContextMenu Implementation order
So if there is any contention for position, there is no consistent way for an extension to guarantee their relative position within the menu.
Obviously you can't do anything about phase 1. Phase 3 only applies to the verbs implemented in your handler. That leaves phase 2. The only thing you can do is name your entry under ContextMenuHandlers such that it would be enumerated first, but nothing's stopping someone else from doing the same thing.
This is for Windows 7, maybe same for newer versions. It was inspired by the other answers, all is affecting the order.
I'm explaining entries for "*" (all files), but the same goes for special extensions.
I take no responsibility for any changes made in registry!
There are three sections in the context menu, as it says in How to Change the Order of Options in Context Menu (from answer by #Anonymouse)
They call them:
2 - Default menu position (at the top).
1 - Send to, copy to folder and move to folder menu part (in the middle).
0 - Rename menu part (at the bottom).
Within these sections the position is decided by the rules in answer by #Luke
The easiest way to change the order within the "section" is to change the name of the registry key under HKCR-*-shell or HKCR-*-shellex. All under subkey shell will be before them under shellex. Keys that have the CLSID as the key name will be as last entry since they are last in the used order.
As an example, I was following a sample from MSDN to build a Context Menu Handler
EDIT 2021-04-14:
The MSDN link is no longer valid, it redirects to a "Browse code samples" page. You can search there for Context menu sample, but the one I followed seems to have been removed.
The closest to the old one I followed is perhaps this
The one I followed is using the CLSID as the name for the key under shellex, and a "friendly name" as default value. It was placed at the bottom of "section" 2 (top section). I changed the key name to something like Asample and changed the default value to be the CLSID instead. Now it was directly after entries under shell.
There are some more ways of changing the order.
For keys under shell you can add the value Position with string data Top or Bottom. Not possible to decide in what "section".
For keys under shellex the value Position has no effect. Instead it's possible to decide in what "section" the entry will be using flags, described in the link above.
Use the CLSID for the shellext you want to move. It's like
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Get it either from the key name or the default value, it depends on how the entry is done.
Find the entry under HKCR-CLSID, the key has the name of the CLSID.
Add a value with name flags and data DWORD with the "section" number described above under the found CLSID.
This did it for me... Steps 4 through 7 - setting the "flags"
http://techoqueries.blogspot.de/2012/08/how-to-change-order-of-options-in.html
This Q&A shows a simple way to CREATE (not move) an item within the context menu. I managed to duplicate an existing item. Then I moved my item to a higher and more accessible position within the context menu, by renaming the key to start with something "aMyItem" or "0MyItem".
I've been trying to find a way to re-order things, it irritates me that the daily use options are pushed to the end, when obscure utilities you might use once in a blue moon are filling up the top of the list.
I found a lazy way to do this, using a little utility package called "Windows 10 Manager" Windows 10 Manager - it's a few quid, but it's a lot easier than registry hacking. It can't do everything, but it does let you add items into the top section at least - and also to suppress cheeky ones that installed themselves in there without asking.
As you can see, it's actually duplicated some entries rather than moving them, but never mind.
I am calling querying the extended window styles of a window using the GetWindowLog property and it is returning values in many cases that are not documented in msdn.
Particularly 0x00000800L and 0x00000100L or a combination of the two. Does anyone have information about these values, or a more complete list than what is documented on the msdn site?
I ran across this thread while looking for an answer to why this value changes when Microsoft Word "disappears" a window. I maintain an app that tracks the HWND values in order to do application sharing. This works well, but Microsoft Office applications often handle these in unusual ways. In this particular case, I found that if you do the following in Microsoft Word 2013:
Open two new documents in separate windows.
Save the HWND values for both windows.
Close one of the two windows.
Both HWND values will, when interrogated with the IsWindow, IsVisible, etc Windows functions, appear to be normal, still visible, etc. There's no way I can find to tell that one of the windows has been closed -- except this undocumented dwExStyle value. 0x800 will be 'on' in the window that's still visible, and 'off' in the window that isn't visible any more.
(BTW, I know you're not "supposed" to save HWND values this way -- but try tracking windows for sharing without saving this value -- not so easy!)
Since 0x00000100L is listed right on the Extended Window Styles page it is a little unclear to me if you mean the normal or extended style so I'll describe both.
Style:
Dialog & old (user32) controls
0xFFFF for control/dialog specific styles
Common control:
0x00FF is generally used by the shared common control styles (CCS_NORESIZE, CCS_TOP etc)
0xFF00 for control specific styles, for a toolbar you would have TBSTYLE_LIST, TBSTYLE_TRANSPARENT etc
ExStyle:
0x00000100L=WS_EX_WINDOWEDGE
0x00000800L=Don't know, undocumented flag maybe (Edit: ReactOS has/had 0x00000800 as WS_EX_MAKEVISIBLEWHENUNGHOSTED, that does not mean that it has the same meaning on windows since ReactOS is not 100% compatible with windows)
Jeremy, this is just a bug of GetWindowInfo (for any OS after Win98: 2k, XP, Vista, Win7).
see http://rsdn.ru/forum/winapi/3362548.all.aspx ("WINDOWINFO.dwExStyle error")
try small tester therefrom: http://files.rsdn.ru/42164/wi_exstyle.zip
kero