Official Microsoft docs for WM_GETICON: https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-geticon
I am confused about ICON_SMALL vs ICON_SMALL2 for Win32 message WM_GETICON:
ICON_BIG: "Retrieve the large icon for the window."
ICON_SMALL: "Retrieve the small icon for the window."
ICON_SMALL2: "Retrieves the small icon provided by the application. If the application does not provide one, the system uses the system-generated icon for that window."
My guess:
ICON_BIG corresponds to WNDCLASSEX.hIcon via GetClassLongPtrW(hWnd, GCLP_HICON)
WNDCLASSEX.hIcon: "If this member is NULL, the system provides a default icon."
ICON_SMALL corresponds to WNDCLASSEX.hIconSm via GetClassLongPtrW(hWnd, GCLP_HICONSM)
WNDCLASSEX.hIconSm: "If this member is NULL, the system searches the icon resource specified by the hIcon member for an icon of the appropriate size to use as the small icon."
ICON_SMALL2
If WNDCLASSEX.hIconSm is non-null, return WNDCLASSEX.hIconSm.
If WNDCLASSEX.hIconSm is null, then return (small) system default.
Reading the official documentation carefully, I do not understand the difference between ICON_SMALL and ICON_SMALL2.
Related
I'm wondering how to add several UI panels to a scripting palette in GMS 2.x. I found some commands in Gatan's outdated documentation (http://digitalmicrograph-scripting.tavernmaker.de/other%20resources/Old-DMHelp/FloatingPalettes.htm) but most of them are not found in GMS 2.32.
Given a UI class "UI_class" (including an init() function that creates the interface) I've already successfully registered the script palette and opened the corresponding gadget using:
object UI=Alloc(UI_class).init()
RegisterScriptPalette(UI,"Type","Display")
OpenGadgetPanel("Display")
Unfortunately, the command GadgetWindowAddGadgetPanel() which seemed to be the most promising to me in the first instance in order to add a second UI to the same palette cannot be found.
Does anybody know a working equivalent?
Thank you in advance for sharing your experience, I'm looking forward to see some nicely designed floating palettes!
I'm not 100% sure I understood the question correctly. Each UI derived object forms it's own "dialog", which can be displayed either as
Modal Dialog - using Pose( DlgObj )
Modeless Dialog - using Display( DlgObj, "name" )
Gadget panel - by first 'registering' it and then displaying a registed dialog
If you have multiple gadget of same width, you can add them together by drag-and drop. This is not part of the dialog - just part of how the UI interaction with dialogs. ( You drag a palette to the side of the screen to attach it, and then you can dragg other palettes on top of it. )
|
|
Example script to produce some dialogs:
Object CreateDlgObj()
{
TagGroup DialogTG = DLGCreateDialog("My Dialog")
TagGroup StrFieldTG = DLGCreateStringField("Some string",20)
DialogTG.DLGAddElement(StrFieldTG)
Object DialogObj = Alloc(UIFrame)
DialogOBJ.Init(DialogTG)
return DialogObj
}
// MAIN
// Show dialog as modal dialog
// CreateDLGObj().Pose()
// Show dialog as modeless dialog
// CreateDLGObj().Display( "NewName" )
// Register dialog as gadget and then display
// RegisterScriptPalette( CreateDLGObj(),"", "RegDlg" )
// OpenGadgetPanel( "RegDlg" )
// Create, register and display multiple dialogs as palettes
number nMax = 2
For( number i =0; i<nMax; i++)
{
string name = "MyDlg_" + i
RegisterScriptPalette( CreateDLGObj(),"", name )
OpenGadgetPanel( name )
}
Note that "Gadget panels" or "tool palettes" or whatever you call them are different in GMS 1.x, GMS 2.x and GMS 3.x as it is always the "main program" which decides how to handle the dialogs. GMS 2.x is the only version, where the program "remembers" the layout of multiple such palettes. These layouts can be saved and loaded. GMS 3 no longer has this, as all UI palettes are fixed in position. (Old custom dialogs still appear, but in a somewhat 'out-of-style' way.
GMS 2.x's "Floating Window Layout" tool:
The "layout" information stored with this tool is actually stored in the Windows registry.
But I have never used that so far. (And it also only applies to GMS 2.x.)
It is also worth mentioning, that RegisterScriptPalette does exactly what is says: It adds the UI permanently to the list of palettes the appliction knows of.
So running the script twice, you get two identical palettes. You usually don't want that! Just use OpenGadgetPanel to show any already registered palette.
However, 'registered' palettes will only remain 'registered' as long as the application is running, so they are gone at restart of DM.
If you want somethng more persistent, you need to install the code as a Library via the File menu. Note, that any executeable part of the code will be automatically run on startup. So you want to have the RegisterScriptPalette be part of that code, but not the OpenGadgetPanel.
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
What should the size of the icon supplied for CFBuldneURLIconFile be?
I'm guessing 57x57 and that having an #2x version present will automatically be loaded where appropriate, but can't find documentation anywhere (Googling 'CFBuldneURLIconFile' returns nothing!)
Do you mean CFBundleIconFile? (Must confess I've never heard of "CFBuldneURLIconFile" - where does this come from?)
Irrespective, there's an Apple Q&A document entitled "How are the icon files in my application bundle used on iPad and iPhone?" that lists all of the relevant icon sizes/default filenames, which should tell you what you need to know.
Irrespective, the default sizes/names are 57x57 ("Icon.png") for the non retina/iPad devices, 114x114 ("Icon#2x.png") for retina devices and 72x72 ("Icon-72.png") for the iPad, if that's relevant.
UPDATE
Think I might have found what you're after. The Information Property List Key Reference doc contains information about the CFBundleURLTypes, which states that it's effectively the URL equivalent of the CFBundleDocumentTypes. As such, you can presumably use the icon sizes it lists within that part of the documentation. (See the "Document Icons" section.)
There is a difference in the description on MSDN, however, I do not understand what the text means what the difference is.
The GetClassName function retrieves the name of the class to which the specified window belongs.
The RealGetWindowClass function retrieves a string that specifies the window type.
As an example using windows calc.exe
From GetClassName you get "SciCalc"
From RealGetWindowClass you get "#32770"
I guess what I'm really asking then is what is a "Window type" versus a "Window class name"?
See the following article: http://forums.wincustomize.com/3258 deadlink
Updated link https://blogs.msdn.microsoft.com/oldnewthing/20101231-00/?p=11863
Summary:
The Real... functions were added to support Windows accessibility. The goal with RealGetWindowClass is to help accessibility tools identify what kind of window it is working with, even if the application did a little disguising in the form of superclassing.
If you ask RealGetWindowClass for the class name of a window, it digs through all the superclassing and returns the name of the base class (if the base class is one of the standard window manager classes). For example, if your application superclassed the button class, a call to GetClassName would return AwesomeButton, but a call to RealGetWindowClass would return button.