Jep,
indeed it would be nice to at least have some kind of return code when trying to load an image.
Ideally, the information should be contained in the "text" property like "##ERROR##" when something went wrong (not even talking about actual error codes...). Or, in case of success, the fully qualified path of the file as you mentioned.
I don't think it possible to add transparency as OS/2 seem to add a background color to everything :-(
Yeah, and I simply can't understand where the problem is:
Basically, from my understanding, all it (the "label" control) is supposed to do is do a print() to a device context. Maybe retrieve the DC from the HWND before, OK... a very "basic" thing to do I would say. I understand however that the handling of changing contents (changing text) and additional events (like clicking on a label control, although not even supported in DrDialog) has its price and makes things pretty complex. Guess I'm just too much used to the features VB gives me in Windows.

I think DrDialog simply had to draw a line somewhere when wrapping API stuff, especially with regards to GDI. We have (I have) to keep in mind that we're talking about a wrapper around an interpreted language! You can't have full comfort and control while maintaining a level of ease and simplicity - regardless what higher-level programming language you use: Once you want full access to the low-level functions, you'll have to deal with the dirty basics involved. Alas, if the development environment doesn't give you the means, well... I guess I'll have to finally learn C to break these limits.

)
On a side-note, I wonder how difficult it is for experienced (OS/2) C programmers to use the "user" control feature/extension of DrDialog... just like Chris did with his drctrl - like for example: Does any such extension is able to support events which are not already in DrDialog? Meaning: Could someone implement a "click" event in Chris image control or is it DrDialog that needs to "trigger" this, also with regards to the event handler function/callback stuff. Ouch.

While we're at it: Does someone volunteer to see if it would be possible to implement a "bitblit" function for DrDialog controls (and their window handles)? That way, we could load image files and make them become e.g. container backgrounds. If rexx/dw is able to do it, why shouldn't there be a trick to make DrDialog use that as well...
Cheers,
Thomas