Hi all.

I'm primarly a C++ developer but I've been trying to complete development on
a C# application with the following basic requirements:
- The app runs in the background is initially hidden from the user,
including the Windows Taskbar.
- The app needs to receive a registered Windows message
- The app needs to "register" its window handle with an unmanaged C++ dll so
that a WM_USER message can be sent back to the C# app's WndProc
- The app needs to display itself when receiving the WM_USER message, and
hide itself after being acted upon by the user.

I ran into some problems along the way and wondered if anyone could provide
some feedback or comments. Especially since I told my project guy this
should be trivial to do in C#, and now I'm wondering if I made the correct
decision. I'm not looking good at this point.

1) In order to hide the app from the Taskbar, the main form's ShowInTaskbar
property would be set to "false", easy right? That action, however, (using
SPY++)removes the WS_APPLICATION style bit and prevents the application from
receiving any registered Windows messages.

2) I initially call a C#-to-C++ wrapper function to give my ".Handle" to the
unmanaged dll. This works for the first time, but when I set the main form's
Visible property to false and minimize the form, "Handle" gets a new value.
Is there some other "handle" I should be using? I work around this by
"re-registering" with the unmanaged dll after minimizing but there have been
a couple of occasions where a zero has been logged. Using FindWindow() in
the unmanaged dll would be acceptable, is there a way to "register a unique
window class"? The window titlebar includes message specific data so the
title changes.

3) I have seen several instances where the main window was shown (Visible =
true), but with no controls on it. Using SPY++, I see the main window listed
with no child controls, and a "WindowsFormsParkingWindow" which contains all
the children for this form. The data on the controls is correct, but it's as
if they are just not on the right form.

4) I also intended for a Windows Service to start the application, which
works, but the application does not survive a user logoff. We have C++/MFC
applications which do a subclassing code trick to accomplish this but I've
not found an equivalent for C# apps.
http://support.microsoft.com/kb/q164166/

5) I have the main form's TopMost property set to true, and after 2 hrs. of
messing around, I discovered the tooltips are showing behind the form. This
is the case for XP as well as Win2k.

One unrelated thing:
1) Once in a while my VS.NET search function starts reporting something like
"no files found to search in". Strangely enough, when I press CTRL+SCROLL
LOCK it starts working again. Not a big deal once you know the trick.

I apologize if I've missed this information but I looked in the groups and
didn't see any real answers to these questions. I would greatly appreciate
any input as to whether some of this behavior falls in the category of
"that's just the way it is", or I'm not doing things correctly, or bugs to
be fixed, or need to look at workarounds. I'm using VS.NET 2003 and .NET
Framework v1.1 and the target OS is Win2k. Needless to say, I've been
frustrated to this point in creating what I "thought" to be a pretty simple
app. My fear (from a schedule standpoint) is that I have to start over in
C++. Thanks in advance for any comments or insults :- ).


- Brad Jones (not CodeGuru guy!)

Re: Item 2, window handle changing. by Brad

Brad
Wed May 18 16:35:26 CDT 2005

It appears that setting the ShowInTaskbar property during runtime causes the
window handle of the form to change. There may be other side effects.

"Brad Jones" <brad@uicnospam.com> wrote in message
news:eIAWhakWFHA.1468@tk2msftngp13.phx.gbl...
> Hi all.
>
> I'm primarly a C++ developer but I've been trying to complete development
> on
> a C# application with the following basic requirements:
> - The app runs in the background is initially hidden from the user,
> including the Windows Taskbar.
> - The app needs to receive a registered Windows message
> - The app needs to "register" its window handle with an unmanaged C++ dll
> so
> that a WM_USER message can be sent back to the C# app's WndProc
> - The app needs to display itself when receiving the WM_USER message, and
> hide itself after being acted upon by the user.
>
> I ran into some problems along the way and wondered if anyone could
> provide
> some feedback or comments. Especially since I told my project guy this
> should be trivial to do in C#, and now I'm wondering if I made the correct
> decision. I'm not looking good at this point.
>
> 1) In order to hide the app from the Taskbar, the main form's
> ShowInTaskbar
> property would be set to "false", easy right? That action, however, (using
> SPY++)removes the WS_APPLICATION style bit and prevents the application
> from
> receiving any registered Windows messages.
>
> 2) I initially call a C#-to-C++ wrapper function to give my ".Handle" to
> the
> unmanaged dll. This works for the first time, but when I set the main
> form's
> Visible property to false and minimize the form, "Handle" gets a new
> value.
> Is there some other "handle" I should be using? I work around this by
> "re-registering" with the unmanaged dll after minimizing but there have
> been
> a couple of occasions where a zero has been logged. Using FindWindow() in
> the unmanaged dll would be acceptable, is there a way to "register a
> unique
> window class"? The window titlebar includes message specific data so the
> title changes.
>
> 3) I have seen several instances where the main window was shown (Visible
> =
> true), but with no controls on it. Using SPY++, I see the main window
> listed
> with no child controls, and a "WindowsFormsParkingWindow" which contains
> all
> the children for this form. The data on the controls is correct, but it's
> as
> if they are just not on the right form.
>
> 4) I also intended for a Windows Service to start the application, which
> works, but the application does not survive a user logoff. We have C++/MFC
> applications which do a subclassing code trick to accomplish this but I've
> not found an equivalent for C# apps.
> http://support.microsoft.com/kb/q164166/
>
> 5) I have the main form's TopMost property set to true, and after 2 hrs.
> of
> messing around, I discovered the tooltips are showing behind the form.
> This
> is the case for XP as well as Win2k.
>
> One unrelated thing:
> 1) Once in a while my VS.NET search function starts reporting something
> like
> "no files found to search in". Strangely enough, when I press CTRL+SCROLL
> LOCK it starts working again. Not a big deal once you know the trick.
>
> I apologize if I've missed this information but I looked in the groups and
> didn't see any real answers to these questions. I would greatly appreciate
> any input as to whether some of this behavior falls in the category of
> "that's just the way it is", or I'm not doing things correctly, or bugs to
> be fixed, or need to look at workarounds. I'm using VS.NET 2003 and .NET
> Framework v1.1 and the target OS is Win2k. Needless to say, I've been
> frustrated to this point in creating what I "thought" to be a pretty
> simple
> app. My fear (from a schedule standpoint) is that I have to start over in
> C++. Thanks in advance for any comments or insults :- ).
>
>
> - Brad Jones (not CodeGuru guy!)
>
>
>



Some progress by Brad

Brad
Thu May 19 10:34:33 CDT 2005

I have a sneaking suspicion that setting the ShowInTaskbar
property at runtime is also at the root of the WindowsFormsParking thing.
My guess is it's kind of like when I was growing up and my parents would
threaten to send me to the babysitter and move away while I was gone : )

Here's what I ended up doing that seems to give me the desired behavior.
- Set the form (in the designer!) to defaults.
- ShowInTaskbar = true (so I can get the registered message)
- TopMost = false
- In the "Load" event, call SetTopLevel(false), the keeps the form
hidden until the processes I depend on are done initializing and
send me the registered message telling me that.
- Then I register my .Handle with the unmanaged dll and wait for the
WM_USER message I need to respond to.
- When I get that, I call SetTopLevel(true), this brings the window to
the
top and shows it in the taskbar, which is what is desired so it can
be
minimized if needed.
- After the user is done, SetTopLevel(false) is called and all seems
well.

An added benefit is that my tooltips are no longer popping up behind the
form (yaaaay!).



"Brad Jones (not CodeGuru Guy!)" <brad@uicnospam.com> wrote in message
news:ORBZDG$WFHA.628@tk2msftngp13.phx.gbl...
> It appears that setting the ShowInTaskbar property during runtime causes
> the
> window handle of the form to change. There may be other side effects.
>
> "Brad Jones" <brad@uicnospam.com> wrote in message
> news:eIAWhakWFHA.1468@tk2msftngp13.phx.gbl...
>> Hi all.
>>
>> I'm primarly a C++ developer but I've been trying to complete development
>> on
>> a C# application with the following basic requirements:
>> - The app runs in the background is initially hidden from the user,
>> including the Windows Taskbar.
>> - The app needs to receive a registered Windows message
>> - The app needs to "register" its window handle with an unmanaged C++ dll
>> so
>> that a WM_USER message can be sent back to the C# app's WndProc
>> - The app needs to display itself when receiving the WM_USER message, and
>> hide itself after being acted upon by the user.
>>
>> I ran into some problems along the way and wondered if anyone could
>> provide
>> some feedback or comments. Especially since I told my project guy this
>> should be trivial to do in C#, and now I'm wondering if I made the
>> correct
>> decision. I'm not looking good at this point.
>>
>> 1) In order to hide the app from the Taskbar, the main form's
>> ShowInTaskbar
>> property would be set to "false", easy right? That action, however,
>> (using
>> SPY++)removes the WS_APPLICATION style bit and prevents the application
>> from
>> receiving any registered Windows messages.
>>
>> 2) I initially call a C#-to-C++ wrapper function to give my ".Handle" to
>> the
>> unmanaged dll. This works for the first time, but when I set the main
>> form's
>> Visible property to false and minimize the form, "Handle" gets a new
>> value.
>> Is there some other "handle" I should be using? I work around this by
>> "re-registering" with the unmanaged dll after minimizing but there have
>> been
>> a couple of occasions where a zero has been logged. Using FindWindow() in
>> the unmanaged dll would be acceptable, is there a way to "register a
>> unique
>> window class"? The window titlebar includes message specific data so the
>> title changes.
>>
>> 3) I have seen several instances where the main window was shown (Visible
>> =
>> true), but with no controls on it. Using SPY++, I see the main window
>> listed
>> with no child controls, and a "WindowsFormsParkingWindow" which contains
>> all
>> the children for this form. The data on the controls is correct, but it's
>> as
>> if they are just not on the right form.
>>
>> 4) I also intended for a Windows Service to start the application, which
>> works, but the application does not survive a user logoff. We have
>> C++/MFC
>> applications which do a subclassing code trick to accomplish this but
>> I've
>> not found an equivalent for C# apps.
>> http://support.microsoft.com/kb/q164166/
>>
>> 5) I have the main form's TopMost property set to true, and after 2 hrs.
>> of
>> messing around, I discovered the tooltips are showing behind the form.
>> This
>> is the case for XP as well as Win2k.
>>
>> One unrelated thing:
>> 1) Once in a while my VS.NET search function starts reporting something
>> like
>> "no files found to search in". Strangely enough, when I press CTRL+SCROLL
>> LOCK it starts working again. Not a big deal once you know the trick.
>>
>> I apologize if I've missed this information but I looked in the groups
>> and
>> didn't see any real answers to these questions. I would greatly
>> appreciate
>> any input as to whether some of this behavior falls in the category of
>> "that's just the way it is", or I'm not doing things correctly, or bugs
>> to
>> be fixed, or need to look at workarounds. I'm using VS.NET 2003 and .NET
>> Framework v1.1 and the target OS is Win2k. Needless to say, I've been
>> frustrated to this point in creating what I "thought" to be a pretty
>> simple
>> app. My fear (from a schedule standpoint) is that I have to start over in
>> C++. Thanks in advance for any comments or insults :- ).
>>
>>
>> - Brad Jones (not CodeGuru guy!)
>>
>>
>>
>
>