Hi all,
I slightly going mad here. I need to check something and have noticed that I am missing Chris Wolgemuths DrDialog extension stuff ("drctl017", a.k.a. "drdialog-controls"). I used to have this... it must have suffered a relocation issue. ;)
I checked his remaining official homepage here at /cdwriting however it only lists versions up to 015... while I know that the latest one is 017 (e.g. used in Tame/2 et.al.).
Can someone here point me to a place where I can get that version (the entire distro incl. sources and readmes...) ?
TIA everyone,
Thomas
I too would like an official distro, but it is my understanding, that there is no such thing, only the DLL (there is also a 016 version of the DLL). You can use the 015 distro, and simply substitute the 017 DLL though. AFAIK, there is nothing new in the later DLLs.
Hey Doug,
thanks a ton. That was also what I suspected (nothing "new" in 017...) although I'ld like to know what the changes are. ;) Hmm... I was actually hoping that Chris came up with an image control that supports a "click" event and providing the pointer coordinates -sigh- and a lot more.
Perhaps I could ask him if a bounty would make sense (if he has the time to do it despite NOM...). What I would desperately need is
- a text control (simple text-out a.k.a. "label") with *transparent* background
- an image control that supports click events (and coordinates...)
If there was someone asking me, I'ld add to that wishlist:
- kind of a rich text box (different color/bold/italic) per character or words
- a container that can have background graphics or pattern
Well, sorry for going OT... again, thanks Doug!
Cheers, Thomas
The dll 017 can be found in the following package
http://hobbes.nmsu.edu/download/pub/os2/apps/graphics/fotoget1011_wpi.zip
As far as I am aware, there is no sources.
David
Hi,
I'd add another point to the wishing list:
- retrieval of the name of the currently loaded image
Reason:
It's now possible to set the name of the file/image, but one has to maintain another variable in the script that contain the path and name of the file currently being viewed. That add some extra coding and it would be nice if one could ask the control if it could load the file (at all) or if there where no image loaded.
The zip-file with Chris DrDialog Controls contain the sources, so it should be fairly easy to tweak it and add some features now that he has written the most of the difficult stuff.
I don't think it possible to add transparency as OS/2 seem to add a background color to everything :-(
//Jan-Erik
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.
Quote from: jep on 2009.02.11, 08:48:09
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