AddGadgetItem image bug, all OS

[freak]

Lets add a bit of perspective:

With your example code from above I did a few measurements which compare your use case (a large number of different images) vs. the much more common use case (same number of items, but with only a few distinct images) with our caching behavior. I measured how long it takes to populate the gadget with the items.

Windows 7:

• Many images: 6 seconds
• Few images: 3 seconds

For fun, I repeated the same on Windows XP (which we still support):

• Many images: 17 seconds! (there you have the reason why we added caching in the first place)
• Few images: 3 seconds

Are you trying to tell me that a speed factor of 2 even on a recent OS is negligible? And are you willing to impose this penalty on everybody who uses the library even if they don't have this problem? If we were to remove the caching behavior, every case would perform in the bad way even if there is only 1 image used in the gadget because a copy of the same image would be added for every item. So your statement that there are no downsides to your suggestion is not true.

I also looked up the history of this particular functionality: It has been virtually unchanged since I ported the library from Assembly back in 2006, and as far as I can remember there have not been any complaints about it so far. So your statement that "everybody" is affected by this must be taken with a grain of salt as well.

Please note that I am not saying that your use-case is not valid. You just have to see the other side of it too. We have to make such balancing decision within the PB commandset all the time and its impossible to always satisfy everybody. If you have needs that are outside of the norm, you may have to resort to using an API solution. This way you have all the freedom to go the route you want to without being limited by our design. And its not that difficult either, because as you have demonstrated above the API way can be mixed with regular PB commands quite easily (which is also something we sometimes go to quite some length to ensure).

I understand your frustration but this is not just about you. Sorry.

[Dude]

Can Fred or Freak confirm for me the following: do we need to use FreeImage() if we're creating a new image with a previous image's identifier?

The following code works, but do I need FreeImage() in there?

Code: Select all

#List1=1

If OpenWindow(0,0,0,200,80,"Window",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)

  ListIconGadget(#List1,10,10,200,80,"Column",180,#PB_ListIcon_GridLines|#PB_ListIcon_FullRowSelect)

  img = CreateImage(1, 16, 16)

  StartDrawing(ImageOutput(1))
  Box(0, 0, 16, 16, #Red)
  StopDrawing()

  AddGadgetItem(#List1,-1,"Red", ImageID(1))

  ; Don't need FreeImage(1) here at all?

  img = CreateImage(1, 16, 16)

  StartDrawing(ImageOutput(1))
  Box(0, 0, 16, 16, #Blue)
  StopDrawing()

  AddGadgetItem(#List1,-1,"Blue", ImageID(1))

  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow

EndIf

[netmaestro]

You're working with static image#'s and so you don't need FreeImage as the second CreateImage overwrites the existing one. If you were using #PB_Any, you would need the FreeImage because a new and different image is being created, leaving the old one intact.

[Keya]

I understand your frustration but this is not just about you.

Correct, it's about EVERYONE who adds icons using AddGadgetItem(), and both of the two options available to them have heavy restrictions imposed only by PB and not the OS. You cannot even reliably call AddGadgetItem(icon) if you have even once called FreeImage, because of this feature, but if you don't FreeImage you quickly run out of handles if your list/combo/tree has more than 10000 items. I still don't understand how these PB-only restrictions are beneficial to anyone.

[freak]

Once again: You are the first person to complain about this in over ten years! Those "heavy restrictions" you are talking about don't seem to be such a big problem for "EVERYONE", or somebody would have stepped forward and said something about it before you.

[Fred]

Ok, I think all has been said about this topic . Locked.