I've found this behavior here whilst searching for a way to open/close windows in viewmodels. I implemented the behavior more or less exactly as stated in that answer, except that I changed the inherited Behavior<UserControl>to Behavior<Window>, as I used the behavior in a Window and not a UserControl.
Everything worked well until I tried to change the window.Show() to a dialog window.ShowDialog(). After closing the newly opened window, it would not reopen again.
I figure that has something to do with the way dialogs work?
Is there a way I can change that behavior so it would work with dialogs as well?
(Or did I actually make a mistake implementing it, causing it not to fully function? (In case it works for other people))
Related
I am testing out GMap.Net using WPF. So far I have only added the GMapControl, as well as setting some necessary stuff (CacheLocation, MapProvider, Zoom etc). The control is working well, except that when I close my window, it takes a while before VS recognizes that the debugging session has closed.
Apparently, my application's process is still running for some time before it terminates - it's not a bug in VS. This delay only appears when I do zoom/pan just before I close the window. I would want to guess something is still running, but I'm not sure how to tackle this problem.
Has anyone encountered this and have a solution?
What is happening is your program is still caching the tiles.
All you have to do is call gMap.Manager.CancelTileCaching(); when you exit your program or close the form.
gMap is what I named my instance of gMap.Net
Sounds like a there is a thread still running. I have noticed that the classes use the IDisposable interface. When you close the application/window, it is recommended that you call the .Dispose() method to clear any resources in use
I'm just starting out with MonoMac in Xamarin Studio, and I've run into the strangest problem:
I a window with an NSButton and a NSTextField on it. By this point I've cut out the event handler on the button, so it doesn't DO anything, except highlight when I click it. The button creation code looks like this:
nsButton = new NSButton(new System.Drawing.RectangleF(0, 0, 100, 100));
nsButton.BezelStyle = NSBezelStyle.RoundRect;
nsButton.Font = NSFont.SystemFontOfSize(
NSFont.SystemFontSizeForControlSize(NSControlSize.Regular));
nsButton.StringValue = text;
...and then it gets added to the window like so:
nsView.AddSubview(control.Handle as NSView);
(because in this part of the code, control.Handle is typed as object, and nsView is the main view on the window).
All runs and works fine at first. But, if I click repeatedly on that button, eventually the window just closes. No error, no exception, and the app itself doesn't quit; menus continue to respond and cheerfully log messages when I use them. But the window is simply -- gone.
It's extremely repeatable: it happens after 21 clicks. If I add an event handler that updates the NSTextField (e.g. hello.Caption="Foo";), then it happens after 19 clicks. It doesn't matter whether I click fast or slow; it's always the same number of clicks. Note that there is no code in the project to close the window, and the window doesn't even have a close box; I know of no legitimate way to close it short of quitting the app.
I am baffled here, and don't know how to debug this further. Does Xamarin have some sort of evaluation limit that closes your windows after so-many events? Is it a framework bug? Any insight will be greatly appreciated.
But, if I click repeatedly on that button, eventually the window just
closes. No error, no exception, and the app itself doesn't quit; menus
continue to respond and cheerfully log messages when I use them. But
the window is simply -- gone.
This "disappearing without a trace" sometimes occurs when an application crashes in native code badly enough. This can occur due to bugs in the binding code or mistakes made in calling the native APIs that corrupt internal cocoa state. I believe you are using MonoMac, and that this particular issue has been fixed in Xamarin.Mac.
You can sometimes get more information from the output window or by attaching lldb to your process.
This turned out to be the same issue as this one, in a slightly different guise.
In short, I wasn't keeping a reference to the NSWindow object, but instead was letting it go out of scope. So the GUI window would stick around for a while, but eventually (after some number of events or other code creating behind-the-scenes garbage) it is noticed and disposed of by the garbage collector. The window is then torn down.
It's all perfectly reasonable once you think of it, and happens under both Xamarin and MonoMac (just at slightly different times).
The simple solution, of course, is to retain a reference to the window until you're truly done with it. Problem solved!
(And yes, I feel a bit sheepish, but hopefully this question will get found by future Mac C# developers, and save them some grief.)
I'm a big fan of taking control of every possible situation on the computer when it comes to making apps. And now that I'm beginning to use favor WPF over WinForms for some things, I'm also beginning to realize that many really cool things are missing in WPF - and searching for alternatives seems to be a never-ending struggle.
Is there an alternative in WPF to e.CloseReason for WinForms?
The different "reasons" manifest as separate events. The Closing and Closed events are related to explicitly closing a window, either programmatically or via Alt+F4 or the close button. The Application.SessionEnding event happens at a shutdown or logoff, and information is exposed by ReasonSessionEnding. The exit code from the process can be read from ApplicationExitCode of the Application.Exit event.
I've been looking around for quite a while, and can't seem to find a good way to do this.
Basically I have a C# process using WPF (which has no visible window), that I need to handle WM_ events in (such as WM_CLOSE or WM_DESTROY for example; so that I can elegantly shutdown when a user chooses to log off or restart their machine).
There are a number of solutions I've seen out there that suggest using System.Windows.InteropServices to call AddHook and provide it a pointer to a function that then becomes the WndProc. The problem with this is, as far as I can tell, it depends on the window actually being visible (and in this case there is no window).
Another way that's suggested but doesn't work is to override the WndProc method of a WinForm, but this process has no visible forms or windows.
I've also found things referring to a Message-only Window. Some kind of invisible window that still receives WM_ events. From what I've seen, this is only available in a Microsoft.WindowsCE.Forms assembly. I added a reference to this assembly in my project and subclassed MessageWindow as indicated at: http://msdn.microsoft.com/en-us/library/microsoft.windowsce.forms.messagewindow.aspx but it still seems to not work. The breakpoints inside the WndProc are not being hit.
Any clue?
Think about what you are asking- if you don't have a window, how could your application receive a window message (considering that messages are sent to a window's handle).
That's like saying "how can I receive email without having an email address?"
Michael Entin covers windows' behavior during shutdown here.
I am 99% sure that all processes running in a user's session are automatically closed when the user logs off anyway, so this shouldn't be an issue. If you really must handle this window message, you can create a hidden window as per Any way to create a hidden main window in C#?
I'm working on a rather big project with my team and after a while, we struck into a big problem.
Infact when we minimize the main window of the application, clicking on the taskbar to restore it results in a "bing" sound (the one that windows uses when you are trying to interact with a background window when a modal dialog is opened on it). I can't restore the window except if I press ENTER button (after obviusly clicking on it).
We are using XNA to render something inside a WindowsFormsHost component in our WPF application and the problem comes out when we change something that is not connected directly with wpf (something inside the rendering engine, so it works only with XNA).
I can't post any code because I don't own any rights of it and would be meaningless because the project is enough big.
So my question is: what are the things that can produce a problem like this one (unable to restore window sound) when you click on the taskbar?
At least I can understand where to search for this bug, because I don't even understand where I shall dirt my hands in.
Important notes: I'm using a splash screen and the problems come up when I do something on a second window (so not directly the main one) which is not modal
Thanks for any suggestion
We solved the problem by finding out that there is a bug with an external component that we used inside our application. Still I don't understand how this bug has been created, if someone has a better answer I'll mark it.