Re: Calling sysdm.cpl from MFC....
"Cameron_C" <CameronC@discussions.microsoft.com> wrote in message
news:A97511CE-757F-4535-AA8C-0671F24DC076@microsoft.com...
Hello once again,
nothing appears to happen. The click is processed, and the call is
executed,
but that is all I have seen.
Here is the code fragment I have been working with.
void CAboutDlg::OnBnClickedAboutSystem()
{
PFN_ENTRY pfnEntryPoint=NULL;
HINSTANCE hInstance=AfxGetInstanceHandle();
HMODULE hModule=AfxLoadLibrary(_T("Shell32.dll"));
if (hModule)
#ifdef _UNICODE
pfnEntryPoint = (PFN_ENTRY) GetProcAddress(hModule, "Control_RunDLLW");
#else
pfnEntryPoint = (PFN_ENTRY) GetProcAddress(hModule, "Control_RunDLLA");
#endif
if (pfnEntryPoint)
pfnEntryPoint(m_hWnd, hInstance, "sysdm.cpl,,0", SW_SHOW);
AfxFreeLibrary(hModule);
}
I tried this code and got the same result as you (the function is called on
every click, and I stepped into the assembler and found that at some point
it simply returns without calling any familiar OS funcs. Certainly not
Shell32.dll - it never went in there (unless I accidentally skipped over
something).
So my guess is that it's simply a bug in the sysdm.cpl applet. Perhaps they
had some problems with double-clicks re-opening the dialog and as a quick
fix decided to just return if hwnd happened to be a repeat...
Further evidence:
-----------------
I tried it from control panel (which can re-open) and noticed something
unusual: If you look VERY carefully you'll notice that for a split-second it
seems as if a little window opens up just before sysdm.cpl is re-launched
(but not the first time!). I am guessing that control panel has dealt with
this problem with it's own counter-hack of creating a temporary HWND to
override the applet's double-click hack bug-fix. Then they just kill the
temp window after launch (it's a blocking call so they probably need to kill
the window in another thread). I could try to get a screenshot, but it
happens very fast, and it's such a tiny little window you can barely make it
out... you know, it almost reminded me of one of those little thought
balloons... (of course wouldn't that be the most handy piece of code to cut
and paste into your message handler if you're working on "Control Panel"?
lots and lots of balloons in that code, so why not?)
// pseudo-code:
CBalloon balloon;
balloon.CreateWindow(...);
balloon.RunAsync();
pfCallSysDm(balloon.m_hWnd,....);
// balloon thread:
case WM_TIMER:
if(++nCount == 10)
DestroyWindow();
That sort of thing. ...and nobody should notice!
Just go and try it, you'll probably see it unless your computer is
exceptionally fast. Also you'll notice the keyboard focus switch away and
back to control panel during this interval.
I didn't see any of this behaviour for the other links there, so that's my
theory and potential work-around.
- Alan Carre