Window not remaining invisible on a client’s PC

[grahamr (work)]

I have a propertysheet-based program, originally developed to be interactive, which has been cobbled together to make it headless on a client's machine. The program is to be started by a program of the clients and so we can't be visible in anyway -no flickering or visibility in the task bar.

I override the WM_WINDOWPOSCHANGING message to stop the windows from becoming visible by toggling off SWP_SHOWWINDOW in the WINDOWPOS structure flags variable.

void CEraseDialog::OnWindowPosChanging(WINDOWPOS FAR* lpwndpos) 
{   
    if ( !m_bVisible )
    {
        lpwndpos->flags &= ~SWP_SHOWWINDOW;
    }
    CDialog::OnWindowPosChanging(lpwndpos);
}

However this seemingly does not occur on my clients machine - it appears visible. I have no way of reproducing this effect. So my first question is any ideas why this is occurring?

Secondly I am thinking about adding some debug messages to find out why this impossibility could be occurring - but since this doesn't happen on any of my office machines I can't debug it here (range of machines from 1ghz PIII all the way up to 2.8ghz, including dual-core laptops). The debug trace needs to revolve around the messages - since that what seems to be cause the failing. The idea I have is to develop a class that could be inherited by the dialog and that replaces the WndProc with it's own, logs the message and passes it back to the original via CallWindowProc. So question two is can anyone think of any easier way or problems with this approach?

And my third and final question is what messages should I be tracking? Too many will hide hide the symptoms and too few will hide the cause.

Thanks, G.

[VictorN]

I have a propertysheet-based program, originally developed to be interactive, ...
I override the WM_WINDOWPOSCHANGING message to stop the windows from becoming visible by toggling off SWP_SHOWWINDOW in the WINDOWPOS structure flags variable.

Hmm, what is the purpose using such a GUI application in the hidden (invisible) mode?
In such a case a console App migh be a better choice.

[grahamr (work)]

Hmm, what is the purpose using such a GUI application in the hidden (invisible) mode?

It's a branding issue. The client wants his front-end to run but use our software for the heavy lifting.

In such a case a console App migh be a better choice.

Because the code was already written and working and simply making it run headless seemed to be the easy way. It works fine on 5 machines here all below 3ghz. My client has run it on 3 machines including a dual-core 3ghz and a quad-core Xeon (over kill since this isn't run often and ideally just once and the processing is serial comms bound).

Also a lot of the logic is contained within the GUI hence the automation but in 1998 (the date of the first check in) the original authors probably didn't imagine 10 years later it would need to be automated.

Prior to this update it was last worked on in 2006 - before I started here.

[VictorN]

OK....
Is it a multithread App?
What is the CEraseDialog class? What does it have to do with a "propertysheet-based program"?

[grahamr (work)]

OK....
Is it a multithread App?

Yes. The App starts another thread which simulates the button presses. Not a great way of doing it but easier than rewriting huge swathes of it.

What is the CEraseDialog class? What does it have to do with a "propertysheet-based program"?

The code contained within CEraseDialog::OnWindowPosChanging shows how I am modifying the WINDOWPOS structure. This function is replicated throughout the program to determine whether the program to display the dialogs or not.

Thanks, G.

[VictorN]

Yes. The App starts another thread which simulates the button presses.

How does it simulate the button presses? Could you show some code?

The code contained within CEraseDialog::OnWindowPosChanging shows how I am modifying the WINDOWPOS structure. This function is replicated throughout the program ...

Do you mean you use it for all the dialogs?
Do you use it also for property sheet itself?

[grahamr (work)]

How does it simulate the button presses? Could you show some code?

Once the app has completed initialising - on return from OnInitDialog, it sends an inter thread message with the hwnd as the lParam. This then decides via the command line options which mode we are running in and posts a fake button press to the relevant button. eg:

		HWND hWnd = reinterpret_cast<HWND>(lParam);
...
		case CommandLineTask::UPLOAD:
			::PostMessage( hWnd, WM_COMMAND, IDC_UPLOAD, MAKELPARAM( ::GetDlgItem( hWnd, IDC_UPLOAD ), BN_CLICKED ) );	
			break;
...

Do you mean you use it for all the dialogs?
Do you use it also for property sheet itself?

Both.

I am checking out if it could be XP SP3 as they have it installed on their work machines and we don't.

G.

[John E]

Dunno if this will help you Graham but I was recently asked to do something very similar. I'd written a program for Windows but someone else wanted to run it under Wine (Wine is a well known Linux utility that runs Windows apps). They wanted to design their own front end and have it call my module to handle the 'grunt'.

My bit was mostly concerned with carrying out a lengthy process so it was appropriate for it to have a progress indicator. I designed a very simple dialog box with the usual OK / CANCEL keys and a progress control. I 'painted' the dialog to give it the same look as my client's app but my client wrote the bit that starts everything off. Their front end simply shells to my process which then runs as a standard dialog-based app. To the user, the whole thing looks totally seamless. My dialog appears as if it's a standard part of my client's app (which is really just my app, re-badged). Maybe that approach could work for you.

No need to hide anything. Just design a window that's deliberately intended to be seen and give it a 'look' that's similar to your client's front end.

[grahamr (work)]

After a bit of discussion (and a quick test-hack) late friday afternoon, between myself and my boss it has been decided to make a simple DLL which the client can call, which was my original choice when the subject was first broached. Obviously the way we went would of been easier (and obviously right) if the client never had the troubles we had.

There will be pain - looking at the logic behind the button presses show that but hopefully it won't be too much - VAssistX will help with the heavy lifting. Also it will help as this will eventually be merged into our main product.

G.