In testing /drawpic's tiling of .ico's I noticed a visual bug and -g switch behavior which doesn't agree with the different descriptions in /help or versions.txt.

(#A)

-gN looks like it assumes that file.ico has only 1-3 icons in it, which is not always the case. THIS link has output.ico, which I created from an online form that lets you combine multiple png's into a single file. I did this to find out whether the visual glitch was being caused by switching to a different size icon of the same image inside the file, but it wasn't the cause. output.ico contains 6 icons of different sizes:

Per /help, -g1 selects the large icon, but is actually loading the smallest 24x24 red bird. -g0 is supposed to select the small icon, but is loading the 32x32 orange. -g2 "actual icon" is loading the same 32x32 orange. -g3 is not mentioned in /help

The v6.2 changelog in versions.txt says -g1 is small.ico which agrees with actual behavior loading the 24x24 redbird. The changelog says that -g2 is large.ico and -g3 is actual.ico, but -g2 is loading a smaller orange than the 128x128 bluebird loaded with -g3.

The order of the icons within the file.ico seems to affect how mirc handles them. The webform always lists the files in alphabetical order regardless of order of selection, so I created output2.ico after having renamed the 6 icons to appear in rainbow order.

The output2.ico seems to behave the same way, except that -g3 is now the redbird icon instead of the bluebird. It seems that -g0 and -g2 are always the orange, -g1 is always the small redbird, and -g3 is whichever filename was alphabetically first which I assume causes it to be the first image in physical order. I don't yet know how it decides to use the 32x32 orange when it was neither first, largest, or smallest.

(#B)

To see the visual glitch:

1. set mIRC to use normal window not +x maximized2. create the test window://window -c @pic | window -fpe2 @pic 0 0 1100 700 | window -ar @pic3. Paste into @pic's editbox://clear @pic | drawpic -lsmg2 @Pic 0 0 480 480 0 0 48 48 output.icoThis displays a grid of oranges, tiled as 10 rows and 10 columns.4. Now do something to alter the window. Either shift focus away and return, such as clicking twice on @Pic's switchbar icon. It now has a squashed 11th row and 11th column of oranges. Same thing happens if you instead grab the right-edge of the window to resize it.5. Repeat #3 and the extra row/column go away until you repeat #4.6. Repeat 3/4/5 after resizing with: /window -f @Pic 0 0 500 700The blink of the wrapped editbox command causes the 11th row of oranges without any extra actions. The 11th row reaching the right edge of the window shows the 11th column of tiling is exceeding the 480x480 size.7. Resize window to original: /window -f @Pic 0 0 1100 700Then repeat 3/4/5 using g3 instead of g2. The 11th row of blue birds is expanded larger instead of squished smaller.8. As I read the syntax for -o, it should allow selecting the Nth icon in a file, but it's being ignored regardless which number I change the 1 into, always showing the oranges://clear @pic | drawpic -lsmo @Pic 0 0 480 480 0 0 48 48 1 $qt(output.ico)9. Resize window smaller: /window -f @Pic 0 0 400 70010. Then tile the oranges at their actual 32x32 size://clear @pic | drawpic -lsm @Pic 0 0 320 320 0 0 32 32 $qt(output.ico)And there are 11 columns and 11 rows of oranges, even though the big-area is 10 times the size of the small area.11. Drag the window wide enough that the (9) command does not wrap. Now (9) draws only 10x10 grid of oranges, until dragging the @Pic size or changing focus away/back causes the 11th row/column to snap into existence.12. In the above examples, I had to create the window with a height of 700 because -f returns the incorrect size if the command is used from a wrapped editbox. If the window is created in the status window with://window -fpe2 @pic 0 0 200 200 | window -a @pic | drawrect @pic 4 4 0 0 200 200 | var %i 99999 | while (%i) { var %a $r(0,9999) | dec %i }... the red square correctly outlines the text area. However if you twice repeat this command pasted into the wrapped editbox in @pic, the window expands to include the extra height of the wrapped editbox command, because the text area doesn't resize until just before the cursor prompt returns to the editbox - though it should know how much of the window was temporarily grabbed by the wrapping.13. In the (3) command, I later realized that 0-48 is 49 pixels and 0-480 is 481 pixels, so I altered the command to have 10 48-pixel squares drawn into a 480 pixel window.//clear @pic | drawpic -lsmg2 @Pic 0 0 479 479 0 0 47 47 output.icoHowever this causes the (3) command to immediately draw a very thin 11th orange column followed by a 12th column of oranges, where the 11th and 12th rows/columns appear to combine into being the same width as each of the first 10. Once the window is drawn this way, steps 4/5 have no effect.

Thanks for your bug report. You have bumped into backwards compatibility. As you may have noticed, the -g switch says you can load a small icon, a large icon, or the actual icon. Small means 16, large means 32, actual means... whatever the API decides to return by default. The -g switch was added a long time ago when icon handling was a lot simpler.

mIRC actually uses several icon loading APIs: LoadImage() (allows loading an icon as close as possible to specified size), ExtractIconEx() (allows requesting either a small or a large icon), and ExtractIcon() (does not allow requesting a specific size), depending on whether the previous API failed.

In short, the -g switch is an old switch. I might be able to extend it to handle a greater variety of icon sizes. However, until then, you will have to use .ico/.dll/.exe files that separate their icons more clearly to allow loading of different icon sizes.