Custom Query (80 matches)

The current Odin builds show the weird behavior of the scroll bar controls: sometimes the handles don't move, sometimes the arrow buttons remain depressed after clicking them with the mouse.

This behavior can be seen in e.g. the standard About Odin dialog (accessible through the system menu of the main window) or in the standard File Open dialog (e.g. in the notepad application).

There was some chatter on OS2World about updating the reported version of WinXP in Odin to SP3. I have run into an app that wanted that as well, though so far increasing the version only got rid of the message that I needed SP3 and did not fix the problem or I would just commit the change.

Index: version.cpp =================================================================== --- version.cpp (revision 21552) +++ version.cpp (working copy) @@ -88,14 +88,14 @@

2, 0, 0, 0

}

},

• Windows XP

+ Windows XP (SP3)

{

0x05005F03, /* Assuming DOS 5 like the other NT */ 0x0A280105, {

sizeof(OSVERSIONINFOA), 5, 1, 0xA28,

• VER_PLATFORM_WIN32_NT, "",
• 0, 0, 0, 0

+ VER_PLATFORM_WIN32_NT, "Service Pack 3", + 3, 0, 0, 0

}

}

};

It is known that there are two system encodings in Windows: the ANSI encoding (used all over in the GUI APIs) and the OEM encoding (used for compatibility with DOS applications and in particular in the command line sessions for file and console output). For God knows what reasons, in some locales, these two encodings differ. For example, in .ru, we have cp1251 (windows-1251) for ANSI and IBM-866 for OEM (this is the same as in OS/2 and MS/PC DOS).

I found out that at least one UI function, MessageBox?(), expects two encodings at the same time for two its different arguments: the window title bar should be in IBM866 while the message text itself -- in windows-1251. I guess this happened to be like that because message text is drawn by Odin on its own (and hence the ANSI encoding is expected) while the title bar is drawn by the system (using the OS/2 encoding which is the same as OEM). This is completely wrong and needs to be fixed. According to Win32 docs, ANSI should be supplied in both cases.