AddGadgetItem restrictions

Post bugreports for the Windows version here
User avatar
Keya
Addict
Addict
Posts: 1891
Joined: Thu Jun 04, 2015 7:10 am

AddGadgetItem restrictions

Post by Keya »

See http://www.purebasic.fr/english/viewtop ... 13&t=67782 for my full report on this crippling bug/design flaw/beneficial feature with no benefits.

Please add information about the crippling limitations imposed by AddGadgetItem() that:

1) On Windows icons can NEVER be reliably added using AddGadgetItem() if FreeImage() has EVER been called, this is a big one. (Actually it affects Linux and Mac too, but they don't seem to repeat handle id's as much so they don't exhibit the 'colliding handle' problem as much, BUT they still don't allow for updated images to be used)

2) Images are NOT added if their image handle has been used before, EVEN if the image has been updated, and EVEN if it's a brand new image that has been CreateImage'd. (All OS)

3) List/Combo images must remain in memory even though they're no longer actually being used. This 1) prevents dynamically updated images and 2) forces unnecessary resource use, 3) slows everything down a lot as now you must call CreateImage for every image needed instead of being able to re-use, and 4) persistance, as they must remain in memory.

4) Images MUST remain in memory, even though they are no longer being used after being added to the list (ie. purely a waste of resources).

5) A maximum of 10000 images can be used on Windows. While this is a Windows OS limitation we would NEVER actually encounter that limit if PB's AddGadgetItem() didn't have this design flaw, as it would allow us to use 1 image and dynamically update that before drawing it into the imagelist.

This is afterall WHY the imagelist maintains its own internal bitmap (which grows by 16 pixels height everytime you call ImageList_Add) - it allows for hundreds of thousands (resource-limited) images added to the list. This is exactly what Windows Explorer does for listing files in its SysListview32 - the EXACT SAME common control PB is using, yet this design flaw prevents full normal use.

Consider the following code:

Code: Select all

hImg = LoadImage(#PB_Any, "c:\icon1.bmp")
AddGadgetItem(#List1, -1, "Icon 1", ImageId(hImg))
FreeImage(hImg)
hImg2 = LoadImage(#PB_Any, "c:\icon2.bmp")  ;because hImg was FreeImage'd its possible on Windows that hImg2 is now the same handle value
AddGadgetItem(#List1, -1, "Icon 2", ImageId(hImg2))
This code is not reliable as even though we've loaded it as a new image it's possible hImg2 is the same handle as hImg (a 'collision'). This typically won't happen with just 2 files, but is easily noticeable when around ~250 files have been opened/closed (or LoadImage'd/FreeImage'd).

Therefore the ONLY way to reliably add new images with AddImageGadget() is to keep all existing images open, and _never_ close them, even though the gadget maintains its own image list (and is therefore unnecessary to keep images open this way, just wasting memory). Doing this you then have a ceiling of 10000 (default XP/Win7/10), but 1) 10000 handles is maximum, you cant open any more files then let alone images, 2) you have to call CreateImage each time which is slow, and 3) 10000 is still nothing compared to the hundreds of thousands+ that the gadgets allow for (example: Windows Explorer uses listicongadget for showing thousands of files no problems, and yes thats just standard SysListview32, not a custom control).

These restrictions are imposed only by PB not the OS (apart from the 10000 handle one, but that wouldnt be a problem if PB allowed existing images rather than forcing new ones) so they should be documented, or programmers will find themselves wasting a lot of time like i have, only to be told that all these problems and PB-specific limitations are not a bug but somehow a "feature", despite not being beneficial in any way and only causing problems and imposing limitations.

These limits and problems are specifically imposed by PB's AddGadgetItem() and not the OS, as I've painstakingly proven over the past 5 days all for nought, and they prevent us from EVER being able to properly use the ListIcon/Combo/ImageLists as they're meant to be used - it doesn't let us take advantage of their internal Bitmap, hence this 1 icon limit if you use FreeImage or limit of 10000 if you never use FreeImage - ie. if your app is Explorer-like you have to hope none of your customers have more than 10000 files in a directory, so these enforced problems and limitations ("beneficial feature" as im told, yet not told a single benefit) must be documented as i've found myself stuck in a nightmare as a result where months of work has just gone down the drain, and with no way out other than Fred telling me to write API versions of AddGadgetItem for each OS myself.

I've already proved with my Windows version that it's possible and VERY EASY to have AddGadgetItem work properly SIMPLY by calling ImageList_Add each time AddGadgetItem() is called (AddGadgetItem() currently only calls ImageList_Add if it detects it hasnt seen the image handle before), which ALLOWS FOR FULL, UNRESTRICTED PROPER USE of ImageList/ListIcon/Combo etc as they were intended/designed for, whereas for whatever reason that makes zero sense to me (other than saving some space if images are genuinely reused, but ImageLists are tiny and PB blindly assumes if its seen a handle the image hasn't changed) AddGadgetItem() specifically ignores handles if they've been used before -- even if they're a brand new CreateImage'd image with different content!! So you've updated your image and told AddGadgetItem to add it, but it ignores your request. </beneficial feature>

Again I can't think of a single benefit from this strange and crippling approach, all I've seen is a lot of restrictions, problems, and ZERO benefits, and despite asking what the benefits were was never told, so it remains undocumented AND a mystery as to why these problems and limitations are beneficial.

Ok, time to learn how to REINVENT THE WHEEL and write my own version of AddGadgetItem that adds the gadget item without the "Have i seen this handle before? If yes use whatever the old image is, ignore the new image" PB-unique beneficial feature. Already done it on Windows but learning the Mac and Linux is going to be fun and Fred isn't helping with what API to call so this is going to be a headache, so i'm still not sure if trying to patch the executable is the best way to go or just write using raw API.

Either way is crazy but what else can I do if I want to use listgadget with icons? Can't use AddGadgetItem().

Sorry for my frustrated rant but thankyou for understanding my disappointment at spending months on a project that is now no longer viable unless I can successfully reinvent the wheel and make my own version of AddGadgetItem() for each OS.

In the meantime there's a TONNE of demos in Tips'n'Tricks which are BROKEN, and the users won't even know because it's a tricky-to-spot problem (as valid icons are used, just that they're wrong/old).
User avatar
Andre
PureBasic Team
PureBasic Team
Posts: 2056
Joined: Fri Apr 25, 2003 6:14 pm
Location: Germany (Saxony, Deutscheinsiedel)
Contact:

Re: AddGadgetItem restrictions

Post by Andre »

I can confirm, that there are problems / different behaviour on Windows/MacOS with using images several times for different gadgets or gadget items. Have seen them myself in my project...

So I will move this report to Bugs-Windows section (of course it should be checked on the other OS too) for further investigation by the team. Then it must be decided if there can be done something on the way it works, or which notes must be added to the docs.
Bye,
...André
(PureBasicTeam::Docs & Support - PureArea.net | Order:: PureBasic | PureVisionXP)
Post Reply