Help or comments appreciated.

[Brad Jones]

<Previously posted in microsoft.public.dotnet.framework.windowsforms>

Hi all. Any suggestions here would be appreciated. Thanks for reading.

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# (vs 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_EX_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. This is not specific to my machine.

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!)

 

[Brad Jones \(not CodeGuru Guy!\)]

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 \(not CodeGuru Guy!\)]

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

 

[[eterra] Dan]

Brad,
I remember from my VB6 days that you could not set the .ShowInTaskbar
property on a form at runtime. This had to do with style bits being set at
the creation of the window. .NET gets around this limitation by destroying
and re-creating your window when the .ShowInTaskbar property changes.
That's why your window handle changes.

I see two options.
1) Re-register with the DLL each time the window handle changes. (You might
need to create a fast-firing timer to monitor the property to ensure the
correct value at all times).

2) Create a new window class from NativeWindow.

Either option seems to hold peril. I hope you get it.

-dw

 

[Brad Jones \(not CodeGuru Guy!\)]

Thanks for the reply Dan,
I agree, the options you mention are bound to give me problems. I've
done a fair share of VB myself but I guess I've never stumbled onto
that particular limitation. I have a sneaking suspicion that setting this
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,
I remember from my VB6 days that you could not set the .ShowInTaskbar
property on a form at runtime. This had to do with style bits being set
at
the creation of the window. .NET gets around this limitation by
destroying
and re-creating your window when the .ShowInTaskbar property changes.
That's why your window handle changes.

I see two options.
1) Re-register with the DLL each time the window handle changes. (You
might
need to create a fast-firing timer to monitor the property to ensure the
correct value at all times).

2) Create a new window class from NativeWindow.

Either option seems to hold peril. I hope you get it.

-dw

<Previously posted in microsoft.public.dotnet.framework.windowsforms>

Hi all. Any suggestions here would be appreciated. Thanks for reading.

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# (vs 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_EX_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. This is not specific to my machine.

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!)