Where are common icons?

[BrewManNH]

It is unfortunate that functions that are hard to use have been made UDFs, blocking the way for easier-to-use versions.

I don't understand this sentiment. How is the making of a UDF blocking any further development of easier-to-use versions?

You can always develop whatever you'd like without ever using any of the "pre-packaged" UDFs if you don't mind reinventing the wheel. You can also expand the original UDF with your own enhancements or improvements, no one is going to complain. I expanded the Array.au3 file to have more support for 2D arrays in a lot of functions, I posted my version of it in the example scripts section and no one cried foul.

[c.haslam]

I forgot to mention that Koda already makes it much easier to create forms with controls. The styles dialogs will (with lazycat's approval) make it even easier: the user will be able to choose from a combination of styles that are known to work or choose his own combination. He will be able to see an example of the styles he chooses immediately, and he will not need to be familiar with Windows constants.

[c.haslam]

I don't understand this sentiment. How is the making of a UDF blocking any further development of easier-to-use versions?

Perhaps "blocking any further development" is not the best phrase. I mean that if a UDF is already in the library, and it is hard to use, a proposal to provide an easier to use UDF will be refused, because that area is already covered.

When I am writing an "application" in AutoIt, I would prefer not spending unnecessary time creating the GUIs.

[BrewManNH]

Perhaps "blocking any further development" is not the best phrase. I mean that if a UDF is already in the library, and it is hard to use, a proposal to provide an easier to use UDF will be refused, because that area is already covered.

When I am writing an "application" in AutoIt, I would prefer not spending unnecessary time creating the GUIs.

I'm not sure that it would be refused outright if there's a compelling reason to change it.

Also, as I stated earlier, if you want to create your own functions to do something easier, it's easy enough to do. There's absolutely no reason to use the built-in UDF's at all if you would rather not. I often create my own functions when the provided ones don't work as I would like them to.

[c.haslam]

I'm not sure that it would be refused outright if there's a compelling reason to change it.

A big reason not to change a UDF is to avoid breaking user's code.

Perhaps if someone else had submitted the RichEdit UDFs, they would expect Windows constants as parameters: the functions would be one-for-one what Microsoft provides. It took a lot of effort to make the UDFs immediately usable while omitting none of the functionality. I think I succeeded. There are two features that are lacking (or were, last time I checked Trac). I couldn't figure out how they work (if they work!), so I did not submit my attempt: the door is still open for someone else to add these features. When they do, no code will be broken. You might like to look at _GuiRichEdit.au3: to get everything to work logically and properly takes lines of code.

I emphasize that the RichEdit UDFs are based on the work of several people over a couple of years. The real breakthroughs were not mine.

[c.haslam]

To get nice transparent icons change this:

original:

$hBitmap = _WinAPI_LoadImage($hInstance, 121, $IMAGE_BITMAP, 0, 0, 0)

new:

$hBitmap = _WinAPI_LoadImage($hInstance, 121, $IMAGE_BITMAP, 0, 0, $LR_LOADMAP3DCOLORS)

EDIT: It's transparent only on default form's color, not on yellow one used in your example.

$LR_LOADTRANSPARENT doesn't work for me at all.

Perhaps this may help with transparency.