win32utils devel - Apr 2009 - win32-clipboard issues and support for additional formats

Hi,

Currently the GetClipboardData() function is declared in windows-pr so that
it returns a pointer. I guess my reasoning was that I was only worried about
dealing with text at the time, so it was the easiest thing to do. But,
I''d
like to support more formats beyond text, i.e. images.

However, this can cause a segfault. If you copy a jpeg image to the
clipboard first, for example, and try to run the following snippet
you''ll
see what I mean.

Win32::Clipboard.data(Clipboard::CF_ENHMETAFILE)

I think the first issue is that we need to redefine GetClipboardData() to
return a long (HANDLE). But that means manually converting the handle back
to a string using memcpy() when it comes to dealing with text. But, since we
don''t know in advance how much text is on the clipboard, we''ll
need to
dynamically allocate a string buffer. How do you know if you''ve
allocated
enough? BTW, I don''t think we can use memcpy_s() in practice, since
it''s not
supported by VC++ 6.

Then we need a generic way to handle text or images:

   # something like this
   def self.data(format = TEXT)
      begin
         self.open
         if IsClipboardFormatAvailable(format)
            clipdata = GetClipboardData(format)
            case format
               when text_format
                  clipdata = get_text_data(clipdata)
               when image_format
                  clipdata = get_image_data(clipdata)
               when other_format
                  # ???
               end
         else
            clipdata = ''''
         end
      ensure
         self.close
      end

      clipdata
   end

Any suggestions?

Regards,

Dan

Hi,

2009/4/17 Daniel Berger <djberg96 at gmail.com>:
> Hi,
>
> Currently the GetClipboardData() function is declared in windows-pr so that
> it returns a pointer. I guess my reasoning was that I was only worried
about
> dealing with text at the time, so it was the easiest thing to do. But,
I''d
> like to support more formats beyond text, i.e. images.
>
> However, this can cause a segfault. If you copy a jpeg image to the
> clipboard first, for example, and try to run the following snippet
you''ll
> see what I mean.
>
> Win32::Clipboard.data(Clipboard::CF_ENHMETAFILE)
>
> I think the first issue is that we need to redefine GetClipboardData() to
> return a long (HANDLE). But that means manually converting the handle back
> to a string using memcpy() when it comes to dealing with text. But, since
we
> don''t know in advance how much text is on the clipboard,
we''ll need to
> dynamically allocate a string buffer. How do you know if you''ve
allocated
> enough? BTW, I don''t think we can use memcpy_s() in practice,
since it''s not
> supported by VC++ 6.
>
I guess the memory size of the HANDLE can be retrieved using GlobalSize().

Regards,

Park Heesob

On Fri, Apr 17, 2009 at 12:31 AM, Heesob Park <phasis at gmail.com>
wrote:
> Hi,
>
> 2009/4/17 Daniel Berger <djberg96 at gmail.com>:
>> Hi,
>>
>> Currently the GetClipboardData() function is declared in windows-pr so
that
>> it returns a pointer. I guess my reasoning was that I was only worried
about
>> dealing with text at the time, so it was the easiest thing to do. But,
I''d
>> like to support more formats beyond text, i.e. images.
>>
>> However, this can cause a segfault. If you copy a jpeg image to the
>> clipboard first, for example, and try to run the following snippet
you''ll
>> see what I mean.
>>
>> Win32::Clipboard.data(Clipboard::CF_ENHMETAFILE)
>>
>> I think the first issue is that we need to redefine GetClipboardData()
to
>> return a long (HANDLE). But that means manually converting the handle
back
>> to a string using memcpy() when it comes to dealing with text. But,
since we
>> don''t know in advance how much text is on the clipboard,
we''ll need to
>> dynamically allocate a string buffer. How do you know if
you''ve allocated
>> enough? BTW, I don''t think we can use memcpy_s() in practice,
since it''s not
>> supported by VC++ 6.
>>
> I guess the memory size of the HANDLE can be retrieved using GlobalSize().
Awesome. Worked perfectly.

Thanks,

Dan