mIRC Home    About    Download    Register    News    Help

Print Thread
Loading .bmp into dialog icon #270519 19/07/22 02:08 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
No matter what I try, same as reported in https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/205088/, I can't get a correct result in showing a .bmp into a dialog icon control.

icon ID, X Y W H, $scriptdirfile.bmp , noborder actual

Let's say the .bmp is 14*14 pixels, and I want the icon in the dialog to show the .bmp as is, not scaled, by setting W H as 14 14, and let's say I use the 'actual' style to fit that. I'll get a tiny control as expected, but the image displayed in it is sort of scaled down to a very small image, some 2x2 dots.

If you increase W and H, the image gets bigger and bigger, but by the time it displays correctly, the size of the control is bigger than half your dialog, which makes it impossible.
I tried to change the size of the .bmp to be 64x64 instead, and it does not change much. Is this feature working correctly? It looks like it's not.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Re: Loading .bmp into dialog icon [Re: Wims] #270524 20/07/22 08:20 AM
Joined: Dec 2002
Posts: 5,150
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,150
Thanks for your bug report. I have not been able to reproduce this issue here so far. I tested with a small 14x14 bmp as well as larger ones and the size displayed was always correct. Note that actual, small, and large apply to icons, not bmps. Can you provide a minimal dialog definition that reproduces your issue?

Re: Loading .bmp into dialog icon [Re: Khaled] #270525 20/07/22 01:11 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
For my report, I had tried 14x14 then scaling it a bit up to 64x64, but it didn't do anything so i wrote the report. After reporting, I scaled to be 164x164 and that showed up ok on the 28x28 sized icon control. This test shows that 128x128 renders the same as 164x164.

Code
dialog icons_bmp {
  size -1 -1 300 300
  option pixels
  icon 1, 5 5  28 28,   $scriptdir14x14.bmp, noborder
  icon 2, 50 50  28 28,   $scriptdir64x64.bmp, noborder
  icon 3, 100 100  28 28,   $scriptdir128x128.bmp, noborder
  icon 4, 150 150  28 28,   $scriptdir164x164.bmp, noborder

}
alias icons_bmp {
  window -hCfp @bmp14x14 -1 -1 14 14
  window -hCfp @bmp64x64 -1 -1 64 64
  window -hCfp @bmp128x128 -1 -1 128 128
  window -hCfp @bmp164x164 -1 -1 164 164
  ;draw pink background and white circle to main 14x14
  drawrect -fr @bmp14x14 16711935 0 0 0 14 14
  drawrect -re @bmp14x14 16777215 3 2 2 10 10
  ;scale to, save and close all windows
  drawcopy @bmp14x14 0 0 14 14 @bmp64x64 0 0 64 64
  drawcopy @bmp14x14 0 0 14 14 @bmp128x128 0 0 128 128
  drawcopy @bmp14x14 0 0 14 14 @bmp164x164 0 0 164 164
  drawsave @bmp14x14 $qt($scriptdir14x14.bmp)
  drawsave @bmp64x64 $qt($scriptdir64x64.bmp)
  drawsave @bmp128x128 $qt($scriptdir128x128.bmp)
  drawsave @bmp164x164 $qt($scriptdir164x164.bmp)
  ;window -c @bmp14x14
  window -c @bmp64x64
  window -c @bmp128x128
  window -c @bmp164x164
  dialog -m icons_bmp icons_bmp
}


[img]https://www.dropbox.com/s/7r8wu0klupquijl/Screenshot%202022-07-20%2015.06.21.png?dl=0[/img]Tested on 7.68 win10, dpi setting normal at 100%


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Re: Loading .bmp into dialog icon [Re: Wims] #270526 20/07/22 04:02 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
Ok after reviewing this with Khaled, my last post shows a bug in /drawsave not saving the correct size, if the size of the .bmp is correct, it nows render correctly and I cannot reproduce the original bug I report. Super weird for me because I was having results where the icon size was 28 28 and a tiny dot was rendered inside it for a 14x14 or 64x64 .bmp, and these were not made using /drawsave.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Re: Loading .bmp into dialog icon [Re: Wims] #270527 20/07/22 04:11 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
Ok I found my mistake, I had not cropped the .bmp when trying with paint, so the size of the .bmp was in fact huge with only 14x14 being filled.
Note that loading a .png into a dialog control icons also seems to work, the help file should be updated.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Re: Loading .bmp into dialog icon [Re: Wims] #270529 20/07/22 04:39 PM
Joined: Dec 2002
Posts: 5,150
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,150
Right, the issue is that /drawsave saves the entire window bitmap, and a bitmap is always at least the size of the window display area.

Since windows does not allow windows to be resized smaller than a minimum width, these means that /drawsave was saving a wider bitmap than you expected in your example.

This cannot be changed. In @windows, a bitmap is always at least the size of the display area in a window.

Re: Loading .bmp into dialog icon [Re: Khaled] #270546 21/07/22 01:52 PM
Joined: Jul 2006
Posts: 3,930
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,930
Ignore what I said above please, I was misreading the bitmap size. Thanks to maroon I also figured something else. I said the bitmap was the correct size, that's wrong.

I've known for decade that it's possible to get a picture @window to be larger than the size of the screen, by calling /window -f twice (it sets the display area as well as the bitmap).
But in fact calling /window -f a second time not only allows the above, but it also get rids of the size limitation mentioned in here, aka the bitmap can be made 14x14 and drawsave does use that size.

I had ignored /drawsize because while /drawsize works, if you look at the thread where it was added, scripters did not ask for this implementation, it would have been more convenient to have a new switch in /window to force the size of the bitmap, as well as force /window -f (which actually sets the display area, and, under normal circumstances, the bitmap will be the same size but..) to require only one call to properly be of the correct size when the size is larger than the screen
I suppose it wasn't made this way because the W H parameter of /window can only refer to the display area (which IS limited in smaller size) where /window would need a second WH parameter via some switches for it to work.
/drawsize it is then, sorry for the mess.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel