DWORD dwType, dwCount;
LONG lResult = RegQueryValueEx(hSecKey, (LPTSTR)lpszEntry, NULL, &dwType,
NULL, &dwCount);
if (lResult == ERROR_SUCCESS)
// ...
Under Unicows this sometimes goes wrong because RegQueryValueEx() returns
ERROR_MORE_DATA, which is treated as failure by MFC.
Strictly speaking, Unicows is within the documented behaviour of
RegQueryValueEx(). The dwCount argument is not initialised and so might be
smaller than the length of the string we're looking for. However, since we
are also passing NULL as the buffer address, most versions of Windows return
ERROR_SUCCESS anyway. They only return ERROR_MORE_DATA when the data itself
is requested, rather than just the length. It looks like Unicows always
checks the lengths regardless of whether the data is requested.
This is arguably shoddy code in MFC. However, it works on just about every
Windows platform except Unicows. And of course since it is in MFC I am
reluctant to fix it. I'd prefer to avoid calling
CWinApp::GetProfileString().
Incidently, I actually found this problem in my own code first - perhaps
someone had copied the MFC example. And it was quite hard to track down.
Because it involves an uninitialised variable, it isn't repeatable. Indeed,
if you step through it twice it will tend to succeed the second time,
because the first time will fill in a reasonable value for dwCount. The sort
of bug programmers hate. I didn't report it at the time because I felt it
was really my fault for not initialising dwCount. However, I expect that
other programmers will have the same problem and now that it is in MFC as
well, maybe it is worth bringing Unicows into line with the rest of Windows.
Or at least documenting it as a fix to be made to MFC when recompiling it
for Unicows.
It's a good catch, info I will definitely use, thanks,
Ted.
"Dave Harris" <dha...@serif.com> wrote in message
news:O3dh%23x3KD...@TK2MSFTNGP12.phx.gbl...