EVC4 SP4 MFC VariantChangeTypeEx Bug

Create a new MFC program.
Add a new Menu. Add a handler for the new Menu Item w/ the following code.

   CComVariant s(_T("100"));
   CComVariant d;
   HRESULT hr = VariantChangeTypeEx(
                     &d, &s,
                     MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT),
                     0, VT_I4 );

   if (FAILED(hr)) {
      CString s; s.Format(_T("Value = 0x%x"), hr);
      AfxMessageBox(_T("Failed Change Type!"));
   } else {
      CString s; s.Format(_T("Value = %i"), d.lVal);
      AfxMessageBox(s);
   }

Scenario:
1. Start up File Explorer. Browse to the executable that contains the exe. Click on the exe to start the application.
2. Click on 'X' on the top right corner to close the application (hide actually).
3. Click on the exe on the File Explorer to bring the application to the front/top. It will bring the application to the front/top.
4. Execute the newly added code through the menu item.
5. Repeat step 2 and 3. Now it fails to bring the application to the front/top. The Taskbar now shows 'Start' instead of 'File Explorer'. Click the exe again shows 'Default Ime'.

To properly bring the application to the front/top, I have to:
1. Go to Start > Settings > System > Memory > Running Programs
2. Select the right application, and click the 'Activate' button.

It seems that VariantChangeTypeEx is causing this to happen. Any advise to fix this Or a workaround Thanks.

Answer this question

EVC4 SP4 MFC VariantChangeTypeEx Bug

Mohit Gupta
I'm seeing similar broken behaviour on VS2005 targeting both Pocket PC 2003 and Windows Mobile 5.0.

Any help is appreciated. Thanks.
TeddyCineas
An addition: when function VariantCHangeTypeEx() (or VariantChangeType()) succeeds, the behaviour is same as reported above. But when it fails, there is no problem.
SJS19859

Hi,

I am a QA in MS. I have reproduced the problem and shall take up this issue to corresponding people. I shall put the results back as soon as I get.
KS16
When the application is launched again, a new instance of the same application is started. The task at hand is to look for a previous instance and bring that previous instance to the foreground. And then, quit the current instance.

Now, there is no code change in winmain.cpp. There isn't any point in you changing winmain.cpp because that's MFC code and it gets compiled to mfc*.dll.

I'm hinting that you are supposed to do what MFC does when starting up. Hope this gives you a lead to solve your problem.

I'm you do need the explicit fix, let me know.
ISJ
I filed a bug for this problem.

I am able to reproduce it on Win32 using the same implementation as MFC.

Actually, I went further to even find a workaround for it. Not the best solution, but it works.

I can't seem to edit the bug report to provide any additional information. Hopefully whatever I found would be useful.

VTaneja, if you can get hold of Sadagopan from VSD Team, please inform him.
NOVA_devel
I encountered the same problem in my application. I'm using a HTML control and when I point it to a URL and minimize the application, I can't activate it again from file explorer on PPC 2003. I noticed that the only solution is to go to Settings -> Memory -> Running Programs and activate it from there.

I tried your code change in winmain.cpp but that code is executed only when the application is started, and not when you try to launch it again when it is minimized. I set some breakpoints when it was minimized and they weren't hit. Not even when I activated the application from the Running Programs menu.

Can you explain what happens when the application is launched again while minimized
EVC4 SP4 MFC VariantChangeTypeEx Bug

Answer this question