Recovery add about+explorer

[Ixentus]

Testbranch for issue 87 ready for testing

[Ixentus]

Trying to launch Explorer as the shell when there is an explorer window open doesn't work. LiteStep should probably force explorer.exe to close.

[jugg]

there are whitespace issues in the RecoveryMenu.cpp

[jugg]

bool bLoop = true;
while (bLoop)
{
// Loop back here if explorer is requested as the shell
// while LiteStep is already running
bLoop = false;

It is non obvious to initialize bLoop to true, then set it to false. Instead change your loop to a do ... while() construct.

WinMain.cpp and litestep.cpp is using a magic number '4'.

if ((nReturn == 4) && !(wStartFlags & LSF_RUN_EXPLORER))

magic numbers are not allowed, use a define/enum.

Also, I suggest changing that to:

if ((nReturn == 4) && (wStartFlags & LSF_RUN_LITESTEP))

in order to be clear that nReturn is being set from StartLitestep(...)

also, blank lines should be filled with spaces to the indentation level of the previous line, there are several lines not doing this in this patch.

[Ixentus]

jugg: The problem is in every previous case nReturn was given a number that didn't come from WM_QUIT, it was also magic, see StartLitestep(). The possible return value's are -1 through 3 (and 4 now). The return value 1 is also hidden somewhere. If I'm going to name them all, I should put them in litestep.h right?

I think i fixed the remaining whitespace issues locally now. I thought indenting whole blocks with spaces as tabs on would automatically put spaces on blank lines as well, I guess it doesn't :(

I will probably fix all this today.

Btw, what do you think of forcing explorer.exe to close in order to get it to run as the shell?

[jugg]

I'd not force anything to close without user consent

[jugg]

whitespace

[jugg]

and yes, litestep.h would be the place for those defines, except you would not be able to use them in lsapi/bangs.cpp as lsapi/* should not include litestep.h

[Ixentus]

I checked for ways to make sure Explorer is launched as the shell, because on Windows XP it is not launched when there is already a file manager window open. On at least Windows 7 it does launch.

I've checked for ways to solve this, however checking for "Shell_TrayWnd" doesn't work because it is not yet created when the input becomes idle.
You can also wait for the "TaskbarCreated" message, but I think creating a window just for this is too much of a hassle (the main litestep window doesn't exist when running this part of the code).

In almost any case when using (not abusing) the recovery menu it should work fine. If it doesn't the user is left with an explorer window which he can use to start litestep, which is good enough to sign off this issue IMHO. Unless someone has a better idea?