Newbie question clipboard

[Mike Hearn]

On Tue, 02 May 2006 09:12:11 -0700, Thomas Hehl wrote:
> Please forgive a newbie. I have extensive development background, but am
> new to wine and, though I've used VB a lot, am somewhat new to API
> programming.

Welcome! Don't worry, we all started in the same position as you did :)
> 
> I have an error while running Pagemaker 7.0 and try to paste text from
> the clipboard that I put into the clipboard from another app. I tried
> running with +relay and got a bunch of stuff. I tried +msgbox to find a
> trace for the message box that's created, but that didn't seem to work
> for some reason.

It might be generated by the app itself ... if you're sure it's a win32
message box look at the relay trace for MessageBox


> 1. On the line: Call user32.GetClipboardData(00000001) ret=00439e26,
> what does the ret mean? Isn't the return value posted later in the log?

Return address, as already said. Can be occasionally helpful, mostly can
be ignored. It's posted twice because as you can see even for a relatively
simple API a LOT of data can be generated in between. It's just more
convenient to have it at that point.

> 2. I haven't found a user32.c and have found many, many hits in the
>source for GetClipboardData that I'm trying to sort through? How do I
> find the source code for that call?

The Wine source tree is a labyrinthe, mostly because it follows the layout
of Windows itself. Believe it or not, it used to be far worse. These days
nearly all the code for the APIs is under dlls/ so if you know where an
API is implemented in Windows then you can find it there.

In this case "user32.GetClipboardData" means it's in user32.dll, which is
implemented in dlls/user (a historical quirk, normally they map 1:1)

I navigate the tree by using etags, which plugs into emacs. If you use
emacs or vi then etags/ctags can be very handy to jump around the tree.
Run "make etags" or "make ctags" (or maybe it's make tags, I forget) in
the source root to generate the file.

> 3. Since I haven't found that, I can't verify the type being passed it.
> It should be CF_TEXT, but without the source, how do I find the value
> for that constant?

CF_TEXT is, like all Windows constants, defined in a header file that can
be found in the include/ directory. Usually the best way is to use grep or
alternatively MSDN will tell you which header file it's probably in.

> 4. It looks like GetClipboardData returned a handle with a value of
> 796d604a, then it immediately locks this. It then turns around and
> unlocks it without doing anything, then never uses this handle again. Is
> this right?

Looks that way. Remember that a relay trace only shows calls into and out
of Wines DLLs. The +snoop channel can be used to see calls to/from native
DLLS. Also remember that programs can do a ton of work between calls that
will never register in the logs. In this case perhaps it's checking the
contents of that memory and finding it's not what it expects?

> 5. After all that, it appears to allocate and unallocate memory and then
> re-open the clipboard. Is it doing this because the last time it tried
> it got nothing? Then, because it returned 0000000, it gave up and
> generated an error?

Could be! To find out why OpenClipboard fails check the traces for that
particular function (you can see which one it uses at the top of the
relevant source file). It might be that the app didn't CloseClipboard last
time for instance.

A word of warning ... this isn't necessarily the cause of the bug. It
could be that if GetClipboardData isn't correct that the app is pushed
onto a codepath the developers never tested and the failing OpenClipboard
call would be the same under Windows. I'm not saying this IS the case,
just that it might be.

You'll need to investigate further to find out.

thanks -mike