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.
Related
I searched but could not find an up-to-date question, so here goes:
Could someone let me know what Xcodes Accessibility Label vs Hint vs Id are used for? I think it might be label and hint are used for voiced navigation and Id's are only used for automation, but not sure if that is right?
You are correct.
The 'Label' property will be used in voice over representing the element itself. If Labels are not set manually, they will be filled in at runtime based on the content of the element. IE: "Comment Delete Button"
'Hints' are also used in voice over assistance but are a more descriptive representation of the element. IE: "This button allows users to delete a comment."
'identifier' is used for automation and quick query of the UI element.
IE: "CommentDeleteButton"
The Label and Hint can be localized and therefore will vary between languages while the identifier remains the same.
https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html#//apple_ref/doc/uid/TP40008785-CH100-SW1
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.)
I would like to know what should I do with GUI layout under WinAPI/MFC.
In the ideal world I should just create the form/dialog via resource editor, and everything should just work. In the real world the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls.
This is where the problem creeps up. Dialog editor uses DLU units, and when I create new controls at runtime, I have to express them in pixel offsets.
I stumbled upon one article about calculating DLUs based on font http://support.microsoft.com/kb/145994/en-us, but also saw a warning somewhere that dialogs can have non system fonts in some circumstances, so this approach is not very safe. Plus the article seems to look only at English characters, without regard to all other characters in unicode space which might be wider?.
Has anyone done a research in this direction and found a better way?
P.S.: No Winforms/WPF/Delphi, requirements.
the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls
It doesn't need to support the controls directly, you can still use it just for positioning by inserting it as a custom control and filling in the window class in the property page. For example, that's how I insert link controls in VS2005: as a custom control with class "SysLink".
MapDialogRect (mentioned in the article) is the function that Windows uses to translate the dialog units in the dialog resource to pixel units. MapDialogRect works (where GetDlgBaseUnits fails) because its given an actual handle to the dialog box, and can send it a WM_GETFONT message to retrieve the actual font the dialog will be rendered with.
I have searched through internet & found that there are no any direct method that disable nodes of CTreeCtrl control.
check one post at http://www.ucancode.net/faq/MFC_CTreeCtrl-CListCtrl.htm & also on codeguru.com but not clear about how to disable node of CTreeCtrl.
Well, I think, the article you linked, speaks the truth: It's not possible (at least not for Windows versions before Vista, see below). You have to program the workarounds recommended in the link to "simulate" item disabling. It means: Give the item a specific colour (light grey for instance) and catch all the events which can occur on a TreeView item and cancel the actions (like expanding/collapsing a node, and so on).
Here, http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/3350ba1e-1fcf-47fe-ab6b-e20c6b5afd91, the statement of the article is more or less confirmed by Microsoft experts. They recommend the same workaround (and actually link to the same article). Also note the link to http://www.codeproject.com/KB/tree/colortreectrl.aspx on how to change individual item colors which might help if you really want to start programming the workaround.
"More or less confirmed" means: There seems to be an exception for Vista and higher:
"CTreeCtrl::SetItemStateEx() supports TVIS_EX_DISABLED (described in TVITEMEX structure) style which disables treectrl node. But its only supported from Vista onwards."
I've seen that sometimes it is talked about a possible value TVIS_DISABLED of the state flag of the TVITEM structure and actually the MSDN of the old VC6 compiler contains a technical article (from 1994 before release of Windows 95 ;)) which says that such a state value should exist with the meaning: "The item is disabled and is drawn using the standard disabled style and color." This article was preliminary ("Please note that this article is based on preliminary information that is subject to change before the final version of Windows 95.") and obviously this value for item disabling did not make its way into the final release of Windows95 as you cannot find it in any VC header files.
So either you can make sure that your program is only used on Vista or higher computers (then it's probably easy with the extended state flag above) or it will be an ugly work (though doable and not necessarily very difficult).
I read about these APIs in this webpage: http://www.ex-designz.net/apicat.asp?apicat=34
I tested TrackPopupMenuEx and TrackPopupMenu APIs and they do the same thing: displaying a menu at the cursor's position. The source codes are the same, you just have to add or erase the "Ex" at the end of the names of these APIs.
Why two APIs for the same action?
Note: TrackPopupMenu crashes my app in runtime when used on an image control, while TrackPopupMenuEx works ok. TrackPopUpMenu seems to have no sense.
They are pretty similar functions but the big difference is that TrackPopupMenuEx allows you to specify a rectangle that the popup menu won't appear over (to have one that doesn't obscure what you need to see). Thats about it as far as i can see.
According to the documentation, there are some subtle differences:
TrackPopupMenu has a nReserved parameter
TrackPopupMenuEx takes a LPTPMPARAMS for the last parameter, but TrackPopupMenu takes a CONST RECT* (which is ignored)
So, they have a different number and type of parameters with different meanings - which would explain why your app is crashing when you change the call.