[REBOL] Re: Update: Read *and* Write images against Windows Clipboard
From: gscottjones:mchsi at: 21-Sep-2002 22:34
From: "Gregg Irwin"
> Here's an upated version of win-clip that let's you
> read *and* write images. The implementation is
> very basic, using an old, obsolete, API call
> (GetBitmapBits) as an initial test. The more
> "modern" approach (i.e. GetDIBIts) will be quite a
> bit more work. If you need a more flexible, powerful,
> up-to-date function (e.g. for palette mapping, bitmap
> conversions, direct JPG support, etc.), that would
> be the way to go. In any case, I'd love to hear if this
> works for people, or if you have any problems on
> specific versions fo Windows or REBOL.
Hi, Gregg,
I've been sitting on the sideline on this one (I haven't taken the /Pro
plunge), but like Brett, I certainly wanted to thank you for boldly going
where no one (seems) to have gone before. Some questions come to mind, and
they are not necessarily focussed at you, per se. But your posting gives a
springboard for asking.
When I peruse the raw rebol executable, I actually can find that many of
these routines are called from within REBOL (not GetDIBIts though). We (the
list
people) have previously been under the impression that clipboard://
can only read and write text from/to the clipboard. So the mystery for me
is, why are these function calls there? I began to wonder how it is we knew
about the clipboard:// scheme to begin with. As far as I can tell, it
started in the /View beta days, and is currently only "documented" on the
rebolforces website, and, of course, it comes up on the list on occasion.
It was one year ago tomorrow when you asked whether maybe it just required
some trick of encoding (or whatever), but apparently no response came. It
was only in March of this year when Holger indirectly implied that binary
clipboard operations were platform specific, and so was not yet supported,
but might be one day.
So, I'm curious if there are other reasons why these function calls would be
in the executable. Anyone have any ideas?
...
> In light of the recent thread on the pros and cons
> of cross-platform support in scripts, let me say
> that this particular bit of functionality, along with
> some other Windows-specific stuff, is required
> for a project I'm working on. The target platform
> is Windows and integration with some other software
> is required. In this kind of scenario, I could do one
> of three things:
>
> a) Try to talk them out of Windows as a target. In
> this case, I think they're making the right choice.
> Supporting other platforms doesn't make any
> business sense at this point.
>
> b) Use another tool for the project. That would
> mean going to a Windows specific tool in my
> case because that's where my background is
> and how I would be most effective.
>
> c) Use REBOL, promote it, and design things
> to make going cross-platform possible in the
> future.
>
> I chose option C.
And a noble choice it is! Viva la Rebolution!
A thought that frequently comes to mind when these threads come up is a
variation on option B. Leverage the rapid development of REBOL with the
broader support available in another cross-platform environment. I've
played with this idea by setting up an echo server that lets me easily
tinker with REBOL interacting with the server. My rough, proof-of-concept
projects have been as simple as getting access to the command line to using
libraries to manipulate images. The proof of concept showed me that it
could work (despite the rough and ready coding), but it means running
another independent process (kind of like running a MySQL server, etc).
I've been rather surprised that we have not seen more of this being done. I
know that I personally like things to be really clean when ever possible,
but as I've said too many times to count, I just salivate at the thought of
all the great supporting extensions that have been developed elsewhere going
unused in REBOL.
By the way, what little I can see, it seems as though other broadly
cross-platform solutions avoid using binary through the clipboard. REBOL
does not stand alone on this issue.
Thanks, again, for your contributions.
--Scott Jones
