Found one more thing worth noting here for future aspiring colorists:Totally agree it’s a weird and hacky assumption no doubt!
For the case when the screen is set to a color mode but I'm trying to get an app's icon using the PlotIconMethod(...,IconGetter,..) methodology - It will call IconGetter twice (as discussed in my recent wave of posts), once for the B&W+mask and once for the OS-determined icon type that needs to be requested for the bit depth of the screen.
Well - in the case where a app only has a b&w icon, and your screen is color, the first IconGetter() call is fine and then PlotIconMethod still calls IconGetter() a second time, now requesting the color icon. So now your IconGetter() function knows it failed, but you don't have a way to communicate this up to the calling function (from the PlotIconMethod side), so PlotIconMethod still plots the data.... which is junk because it never found any color data.
First I got around this by adding logic to my existing structures that basically can track the result of the PBDTGeticon(..) function for each call (the b&w+mask call and the subsequent color call) and if the color call failed but the b&2 call succeeded then I just plot the B&W handle data manually over the garbled mess PlotIconMethod plotted... However - there is a more generic and automatic way to do this. If you return nil; for the IconGetter call that fails to get color icon data, then PlotIconMethod automatically just plots the B&W icon!
I double checked Inside Macintosh's sections on PlotIcoMethod and icon getter functions and did't see anything about returning nil when you don't find requested icon data nor does it mentioned the benefits that automatically fall out if you handle it that way... Though it is fair to say it's self-explanatory to return nil when you're supposed to return a handle to data and that data doesn't exist... and maybe IM has that rule listed elsewhere in some more-generic section(?) but def. not in the specific Icon Getter portion of IM that I read! -->Edit to add that from a cursory check that functions in the toolbox that are supposed to return a handle all fit the paradigm that when the desired data is not found (or otherwise couldn't be provided) that they will return nil.
Last edited: