views:

92

answers:

1

I'm trying to debug and resolve some issues with a Win32 macro application written C++ however I'm having the strangest issue.

I have to launch a 16-bit program and then simulate entering data into and have been using ShellExecute for over two years now. I haven't touched this actual code at all, but now it doesn't work.

I'm doing ShellExecute(NULL, "open", exe_path.c_str(), NULL, "", SW_SHOWDEFAULT);. This has worked flawlessly for years but all of sudden, it stopped working. It gives me an ACCESS_DENIED error code. I've Googled and apparently this is a pretty common issue with launching 16-bit apps.

The workstation XP SP2 environment hasn't changed at all, and it was actually working until I rebuilt a little while ago (I've rebuilt it before many times).

The code is inside a window procedure function and when I take it out and launch the program in the WinMain function it works, but the code has to be in the window procedure...

I've tried numerous alternatives but they all give the same issue.

The biggest issue with this is it was working then all of a sudden decided it wasn't going to with no change to both code and environment! In fact, it was about half way through testing changes that it thought it'd stop working.

Please help as I cannot do anything without the program launching. It's the first step in the code that I'm debugging!

+1  A: 

I've discovered the issue. I changed the lpDirectory parameter (of which I was supplying NULL or "") to the directory of the executable, using the PathRemoveFileSpec() function.

The application is launching again. Now I can continue fixing the rest of the program!

Nick Bedford
So there was a change to the code? :P
Ion Todirel
A change that fixed the no-change-break :P
Nick Bedford