Help fixing updown (comctl32) bug?
C. Scott Ananian
cscott at cscott.net
Sun Mar 13 13:09:33 CST 2005
I have an open-source Windows application I'm trying to get to run under
Wine (sd -- it's in the wine applications database).
The particular issue I'd dealing with (at the moment) is a UDM_GETPOS
message to an updown control. This is the code in the source application.
SendMessage(GetDlgItem(hwnd, IDC_SEQ_NUM_OVERRIDE_SPIN), UDM_GETPOS, 0, 0L);
Under windows, when you just click 'ok' on the dialog without touching the
updown control, this SendMessage returns '0'. Under wine, it returns
65536. Looking at the code (wine-cvs/dlls/comctl32/updown.c:2049):
temp = UPDOWN_GetBuddyInt (infoPtr);
return MAKELONG(infoPtr->CurVal, temp ? 0 : 1);
So, the different between Windows and Wine is that 'GetBuddyInt' (or its
equivalent on Windows) is returning TRUE on Windows and FALSE in Wine.
Digging down a level, the first lines of code in UPDOWN_GetBuddyInt are
static BOOL UPDOWN_GetBuddyInt (UPDOWN_INFO *infoPtr)
WCHAR txt, sep, *src, *dst;
tracing through GetBuddyInt in Wine, this is as far as it gets. IsWindow
returns FALSE, and so GetBuddyInt returns FALSE. But this is very
puzzling: if I click one of the controls on the updown control,
GetBuddyInt will eventually return TRUE. I don't really understand
the purpose of the 'IsWindow' call here -- can anyone who understands the
code a bit better explain to me how infoPtr->Buddy could get
'de-windowized'? I don't see anyplace in the code where Buddy gets
reassigned, and turning on tracing doesn't show anything suspicious, and
I've having great trouble getting gdb to set an appropriate watchpoint
for me. Does anyone else have any insights?
KUCAGE KMPLEBE class struggle Cocaine UKUSA SCRANGER early warning
colonel Bejing AELADLE LICOZY for Dummies ammunition ESODIC Treasury
( http://cscott.net/ )
More information about the wine-devel