Help or comments appreciated.

Discussion in 'ASP .Net' started by Brad Jones, May 18, 2005.

  1. Brad Jones

    Brad Jones Guest

    <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, May 18, 2005
    #1
    1. Advertising

  2. Re: Item 2, window handle changing

    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" <> wrote in message
    news:etYr$...
    > <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!\), May 18, 2005
    #2
    1. Advertising

  3. Re: Window handle changing

    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" <> wrote in message
    news:etYr$...
    > <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!\), May 18, 2005
    #3
  4. Brad Jones

    [eterra] Dan Guest

    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" <> wrote in message
    news:etYr$...
    > <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!)
    >
    >
    >
    >
    [eterra] Dan, May 18, 2005
    #4
  5. 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!).


    "[eterra] Dan" <> wrote in message
    news:uZJDgO$...
    > 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" <> wrote in message
    > news:etYr$...
    >> <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!\), May 19, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    406
    Roedy Green
    Sep 22, 2005
  2. Deryck
    Replies:
    7
    Views:
    470
  3. windandwaves
    Replies:
    18
    Views:
    692
    Spartanicus
    Mar 19, 2005
  4. planetthoughtful
    Replies:
    6
    Views:
    374
    Kent Johnson
    Dec 14, 2005
  5. Brian L. Troutwine
    Replies:
    5
    Views:
    283
    Nick Craig-Wood
    Jun 4, 2007
Loading...

Share This Page