I have a weird situation where I open a form from my application, hide it, and when I try to show it a second time, the Visible property says true, TopMost true also, location is correct, yet I can't see it.
Any ideas where and what to look at to work out what the problem is?
(Note: there may be issues with event handlers/delegate, but I'm not too sure where to start)
UPDATE - I set ShowInTaskbar to true - and I see it in the taskbar, but no way to bring it to front, and right click on the taskbar button does nothing. Alt-Tab neither. Doesn't show up in TaskManager.
Tried Crack.NET, but can't find any properties which let me get 'into' the object instance. .Net Memory Profiler doesn't help for this, I believe, and Winspector I'm not sure what to do with.
UPDATE2 - I lied, it's not directly a WinForm, I was inheriting from a custom class which in turn inherits from WinForm. I tried inheriting directly from Form and it works. So now I've got to go and look in the code of the custom class. I'll keep you posted...
Could it be out of the screen boundaries? (that is, moved out).
Use Spy++ or Winspector and try to find this missing window and see exactly where/why it's hiding.
OK, nailed it.
The Custom form class has a 'cool' function - it fades in and out.
But only once, apparently.
So the reason I couldn't see the form is because the Opacity was 0!
Is the parent Window visible?
Windows has rules about children of non-visible windows being non-visible whatever their own visibility.
Related
Is it possible to get a screenshot of a window that is not on the top, i.e. if it is partially hidden by another window, without bringing it to the top?
Unfortunately, it's not trivial to take a screen-shot in C# at all, you can create a graphics object based on the current window or viewport and capture that, but its not what you're asking for.
This
Screenshot of Hidden Window
might help, but you'd have to do this with Interop code anyway.
I dare say that it's not a common thing that is supported as really, one program has no business knowing what's being displayed in another program; it's potentially a nasty exploit.
You dont need to take screenshot, if it is your application you can use Control.DrawToBitmap(Bitmap bitmap, Rectangle targetBounds); of the form object.
If it is other application window, you can try un-managed way to get the UI of window. I dont remember all the methods but I have tried and it was working. Probably GetWindow and SendMesage with WM_PRINT / WM_PRINTCLIENT
I am using WinForms for a C# project and my main form has a simple button that uses ShowDialog(this) on a second form to show it.
Like this:
if (myParameterForm.ShowDialog(this) == DialogResult.OK)
{//stuff happens}
As per my requirements, when the child form is visible, you cannot access the parent form.
For the past year this child form has been the bane of my application as it mysteriously manages to hide behind its parent form from time to time. The reason this is such a big problem is because the software is designed to be used from a touchscreen kiosk, so the user only has access to a touch-screen, but the child form has locked input from any form but itself till it is acknowledged (closed with ok or cancel).
On load the child form uses "this.TopMost = true" just in case, I added this as an effort to fix my problem.
I use no other visualizing functions on the child form, the thread calling the form literally waits there till the form is closed.
Since the user has no access to a keyboard, or anything but a touchscreen I'm miffed as to how the child form manages to hide behind the parent form. I actually have been unable to replicate the behavior, and have only seen it as a result of responding to service requests.
I want to avoid using a timer to continually check if the form is TopMost because it just seems wrong. Should I reconsider? What event could possibly be occurring that is banishing my child form backstage?
I've tried using the search, but as far as I can tell I'm doing this correctly... Assuming that there is some sinister 3rd party application causing occasional hijinks, what is the best way to detect and rectify this situation automatically without throwing in a periodic check? I am not sure that the VisibleChanged event is what I'm looking for.
I can reproduce the behavior you are describing by minimizing the child window when it is displayed using ShowDialog. Is it possible that something is minimizing the child window? You could try disabling the control box for the child window to see if that helps. I would probably also set ShowInTaskbar to false for the child window (for usability reasons).
I would probably just implement the child form as a dynamically loaded user control instead. When you need it just load it on top of everything else. This way your main window is always in focus and the content you want to display is on top. this will obviously be a bit of work, but judging by the fact that this has been a problem for a year, you probably don't mind the work if it fixes the problem. There may be more intricacies that you'll have to deal with(i.e. having to make all other controls invisible until the child is done, etc.) but I think this is the easiest and most reliable fix.
In my experience TopMost windows and modal dialogs never behave very well ... as you can lock yourself out if a TopMost window happen to cover the modal dialog control. Are you applying TopMost to the main window anywhere in your code?
I implemented something in Windows Forms similar to DragMove but with boundaries set to 10 units of the margins of the primary screen.
When switching over to WPF I found this thread to be useful in achieving the same result.
However, since this is a post-move event, what happens is that if my window is dragged beyond the boundaries I set, it "jumps" back. I would like to avoid this effect as it looks terrible.
Is there a simple way to avoid the window to be moved outside a given area without using the LocationChanged event? I basically want to restrict the movement of the window before it happens.
These this are very hard to achieve with WPF because it does not expose the base Win32 functions and events like WinForms did. I had a project where I needed to to resize a window and I had to use PInvoke SetWindowPos to do this in a normal manner.
AddHook may help you, but this will still be quite difficult. See http://www.wpfmentor.com/2009/01/how-to-get-hwnd-and-hook-into-wndproc.html and http://msdn.microsoft.com/en-us/library/system.windows.interop.hwndsource.addhook.aspx for more information.
I've a winforms app that "docks" to the taskbar
I'd like to autohide the form and make it appear only when the mouse goes near/over the form
any suggestions ?
Install a global hook onto the mouse-move event and check to see if it is within the form boundaries. Should work even with the form hidden. If not just store the location as a rectangle and check against that.
Code for a simple and handy global hook implementation can be found at:
http://www.codeproject.com/KB/cs/globalhook.aspx
I've used this method to create "hotspot" functionality to a user desktop.
I'm not sure it is exactly answering your question, but there is a sample of this on Codeplex...
http://remoteaccessmonitor.codeplex.com/
Browse the source code and check out the MinimizeToTray.cs file - it has examples of pop up messages when hiding and I think its default behaviour is to re-appear on click (although I imagine this could be changed).
You could.
Poll mouse coords until it's within a certain radius of your app.
Position an invisible, always-on-top form above the docked app and have it fire a MouseEnter event.
That's all I can think of really. Either.
For some strange reason, my toopltip in the VS 2008 C# winforms application shows up behind the form! It's very frustrating and I can't figure out what I should do. Anyone face this before? Ideas?
(PS - I'm doing a toolstip.show programmatically within the form)
There are a few things you might want to check:
Make sure the tooltip knows what its parent window is.
Make sure the window the tooltip belongs to is in the foreground (no, this isn't a requirement for displaying tooltips, it just helps debug.)
Try giving focus to the owner of the tooltip. If that fixes the problem, then there's probably an ownership problem with your tooltip.
Try bringing your page element to the front. (Right click on element, bring to front). Is this happening on all tool tips you have configured? And no, I have not seen this before
There is a similar (and known) problem with tooltips appearing behind the Windows task bar. The problem is sporadic and I have never seen a solution. If you're also seeing this behavior sporadically (and I suggest that you try this on different machines), then it may be related. Otherwise, if the problem is consistent across multiple machines, let's see your code, because you're probably doing something wrong.
I have a similar issue. I have a user control written as C++ WTL, being used in a C# .NET2 app. If the control is just on the form then the controls tooltips work fine, however if the user control is on a panel or in a group then the tooltip is behind. I've tried changing the WTL code to force the tip to the front, this works but causes issues with lost focus/selection in other controls.
This problem is almost always caused by the window being TopMost. Try using SetWindowPos to set your tooltip to HWND_TOPMOST. I haven't tried this though...
I've seen this issue happen in both Windows.Forms and Delphi (native windows) based applications, caused by the interaction of "stay on top" with the Windows API.
Essentially, marking a form as TopMost makes it stay on top of some windows, but not others - Window management has more than two distinct levels.
What I found is this: my applications would behave themselves when run normally, with tooltips showing on top. Problems would occur when switching to- and from- other applications - somehow the "TopMost" of the windoww would become "very-ultra-top-most" (non-technical term ;-) ) with the tooltips appearing behind the window.
Having described the problem, I'd like to offer you a solution - but I never did find a good one. Sigh.
Hope that the additional information will be enough for you to find the solution you need.
I have seen this happen on Windows XP, particularly on the taskbar.
Are you sure it's an issue with your application, rather than the OS?