Forum > Unix
menu item bitmap visible? laz v2.0
OH1KH:
Hi again, myself!
Modified source a bit, but no help. Then compiled it with old laptop Lazarus 1.8.2 (Fedora28 x64).
AND IT WORKS !!
So there is a bug in 2.0.0. or the component handling has totally changed.
wp:
What was changed in Laz 2.0 is the imagelist which supports images at several sizes for various screen resolutions now. It is possible that handling of the bitmaps directly assigned to menu items has been affected this way on gtk2. I can confirm the issue on a VM with Lubuntu/gtk2 (32 bit). The issue does not appear on Windows.
I cannot give you a direct solution of the issue since I lack knowledge in low-level gtk2 programming. But why, after all, do you assign bitmaps to menu items directly without using an ImageList? I am always using ImageLists and have never seen issues with it, and in fact, before your post, I did not even know that direct assignment of bitmaps is possible.
The attached demo extends your program with an ImageList and works also on Lubuntu/gtk2. It is a bit simplified because it does not take advantage of the new high-dpi features of the ImageList.
I am aware that my code requires you to change your code at a few places. But you will be rewarded by being prepared for high-dpi icons in the menu.
OH1KH:
HI !
Thanks! Seems to work "as in old days".
Why I assign bitmap directly. It is the easiest way! My code even had too many lines as I first create bitmap and fill it and then assign it to menuitem's bitmap. Same can be done directly to menutem's bitmap. (My last post's unit1.txt)
It just happened to stop working on ver 2.0.0. but works with ver 1.8.x OK
Where I do need the imageList for? I just need one image (or plain bitmap) to get different colors and drop that to menuitems (or access them directly...unfortunately not any more)
Actually I was quite near to start testing something like your demo, but as I never have used image list for any purpose I tried to survive first without.
I even tested with one single image and tried to drop it to menu.bitmap. Same result.Nul.
Thank you.
Saved lot of my time.
Spent already 2 evenings with testing all variations. Noticed that sizing menuitem's bitmap does affect the size of item so it somehow reads bitmap and reacts to it but does not make it visible.
wp:
After playing with your issue I found a less disruptive solution: It seems that the bitmap painted by a uniform color out to its very edge is interpreted as being transparent - you remember that the left-bottom-most pixel is the transparent color? I don't know why switching Bitmap.Transparent to false does not help here, but you can work around by filling the bitmap with the Rectangle function instead of FillRect - you only must take care of the Pen.Color being different from the Brush.Color. The border of the rectangle will now be taken as transparent, but the inner fill will appear. The color box is smaller by 1 pixel on each side, but you can compensate it by incrementing the bitmap width and height accordingly by 2.
This code works for me on Lubuntu/gtk2:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TForm1.Setbitmap(bm: TBitmap; col: Tcolor);begin with bm do Begin Width := bmW + 2; Height := bmH + 2; with Canvas do Begin Brush.Style := bsSolid; if col = clBlack then Pen.Color := clFuchsia else Brush.Color := clBlack; Brush.Color := col; Rectangle(0, 0, bmW, bmH); end; end;end;
wp:
--- Quote from: OH1KH on March 22, 2019, 07:13:06 pm ---Where I do need the imageList for? I just need one image (or plain bitmap) to get different colors and drop that to menuitems (or access them directly...unfortunately not any more)
--- End quote ---
Yes, an ImageList is probably overkill here for just providing a single user-drawn bitmap.
But in general, imagelists provide a generalized container for all images used by an application. You just add the images to the list (by double-clicking on its icon on the form and using the image list editor dialog), and then any image-aware component refers to its image by the index on the image list, the ImageIndex property. Suppose you have a menu and a toolbar and somewhere a speedbutton - all three are for saving a file and look good if you assign the well-known floppy icon to them. Using your method with the direct bitmap property means that your form must contain three copies of the same image - in the image list, however, it is stored only once.
The other advantage is that, since Laz 2.0, image lists can scale the images according to the resolution of the system on which your program runs. In the old days, a screen usually had 96 pixels per inch, and a 16x16 pixel bitmap had a usable size. Today high-dpi screens are popular and have resolutions of 192 dpi or more. When the size of the monitor is appoximately the same as before the size of the 16x16 bitmap now appears to be only half of the old size or less. It is very difficult to hit such tiny icons with the mouse. And an application with huge letters and tiny icons looks terrible. The new imagelist can help to overcome these issues along with the LCL form scaling.
Read the wiki to learn about the ImageList. It's worth the effort.
Navigation
[0] Message Index
[#] Next page
[*] Previous page