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
Related
Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
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.
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
I have a dialog that includes file selection and it has a "Browse..." button. But it seems like it would be a good idea to provide some kind of drop target so that the user can use his/her favorite file browser to select a file (or files) and drag it onto my application.
Is there any standard practice for what to use as a drop target?
Is it a file icon of some sort? what would that look like?
I tend to think that drop targets should be where the file "should land". That is, if I had a browse button and file path editbox, I'd make the path box the target. If I made a document editing application, I'd make the entire editing area the drop target (unless that would make an embedded object of course ... :-P who said these things are easy?)
So I'd say it depends on the application. But having a dedicated, separate target with no other purpose than to drop things on may not be the best solution, since it unneccessarily clutters the interface even for people who will never be interested in using the feature.
In Safari (on the Mac, at least), a file-chooser form element (Consisting of a "Choose..." button and a field showing the chosen file's name) is also a drag-and-drop target. (Contrast with Firefox, which treats the whole window as a drag-and-drop target, and will replace the current page with the dropped item.)
Other places, I've seen an inset box, sometimes with a centered, grayed-out "Drag items here" text which disappears if anything is dragged in.
As Ruddy said, I don't recall any standard icon for the drop idea. There is one for the no drop as shown in this image
(source: west-wind.com)
Otherwise I tend to like this kind of drop explanation; I find them pretty explicit.
Usually if a window accepts files for drag'n'drop - it just accepts them anywhere in the window.
If you have a list of files (listbox/view) or an just an text box that accepts a single file, those individual control windows could be the drop target rather than the entire window.
Normally there is no visual indication that a window accepts file drops. The only indication would be that you try it and you don't get the no-drop cursor when you drag across the window.
(Note: this is under MS Windows, other os window systems may have different standards)