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. ui_options.sequence_num_override = 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): case UDM_GETPOS: 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 (wine-cvs/dlls/comctl32/updown.c:267): static BOOL UPDOWN_GetBuddyInt (UPDOWN_INFO *infoPtr) { WCHAR txt[20], sep, *src, *dst; int newVal;
if (!IsWindow(infoPtr->Buddy)) return FALSE; ------- 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? --scott
KUCAGE KMPLEBE class struggle Cocaine UKUSA SCRANGER early warning colonel Bejing AELADLE LICOZY for Dummies ammunition ESODIC Treasury ( http://cscott.net/ )