|
Hello.
In my windows application I have a subclassed Form (MyWin) that is opened as a top level window with myWin.Show(). MyWin contains a RichTextBox where the user is supposed to type in text. When myWin is closed by the user the text is saved to a file. I implement this by overriding OnClosing in MyWin and save the text from the RichTextBox there. This works fine when the user explicitly close myWin. But since myWin isn’t the main window in the application myWin can be closed implicitly when the application exits. When this happends the overridden OnClosing function will not be called, so the text will not be saved in this case.
I have tried to add a delegate to Application.ApplicationExit and Application.ThreadExit from MyWin to save the text from there. But that doesn’t work because when these delegates are called the RichTextBox has already been destroyed and its Text field is empty. I want MyWin to be autonomous so I don’t want to be dependent on some Save function that must be called when the main window closes.
So, what I need is someway to detect when the application is about to close, something like Application.BeforeExit but I cannot find anyway to do this. I thought that if I could retrieve the main window in the application,from MyWin, I could add a delegate to its Closing event, but I cannot find any way to do this. I have searched and found Application.Current.MainWindow in PresentationFramework, which I don’t know what it is, but when I try to use this the Application.Current is always null.
So, if anyone knows how to detect when the application is about to be closed before anything is actually closed I would appreciate some help.
Regards
Peter
|
|
|
|
|
Hi,
[EDIT}Use the FormClosing event, not the Closing event![/EDIT]
if the MainForm opened some OtherForm which may hold dirty data, then MainForm.OnFormClosing should perform an OtherForm.Close(), and of course OtherForm.OnFormClosing should deal with the dirty data.
BTW: If keeping track of which forms got opened is too difficult, you could rely on Application.OpenForms and try and close those Forms one by one.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
modified on Sunday, August 23, 2009 4:24 AM
|
|
|
|
|
See you can add new Class and a Method in that Class.
Then you can add a Handler for Application.Exit event which references the above Class method.
See below Code.
Class File Code:
Public Class ShutDown
Public Shared Sub OnShutdown(ByVal sender As Object, ByVal e As System.EventArgs)
Try
Catch ex As Exception
Finally
End Try
End Sub
End Class
Form Code That Loads When Application Starts:
Sub New()
InitialiseComponents
AddHandler Application.ApplicationExit, AddressOf ShutDown.OnShutdown
End Sub
The Above Code would Catch the Application.Exit event and run the OnShutDown Procedure.
You can write the Code that you want to Execute in the OnShutDown Method.
Hope This Helps.
|
|
|
|
|
I think you may be looking for a specific Windows message... You can override PreProcessMessage in your form and basically "hook" all manner of unusual things. I wish I knew which one you were looking for exactly or if it even exists, but whenever I've had to handle unusual user actions that didn't really exist as ordinary events, this has worked for me. It's just been a matter of finding the correct combination of msg.Msg, msg.HWnd, and msg.LParam that you are looking for in the overriden PreProcessMessage routine.
|
|
|
|
|
Override OnClosed in MyWin instead of OnClosing. The RichTextBox.Text property will still be valid. MyWin.OnClosed does get called when the main form is closed, whereas MyWin.OnClosing does not.
Eagles my fly, but weasels don't get sucked into jet engines.
|
|
|
|
|
The Closed or FormClosed events are too late to interact with the user.
Use the FormClosing event, not the Closing event!
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Hi Guys,
I have created an assembly containing Tasks for use with MSBuild. In order to get the build working across all development machines, i have placed it on a shared directory. The assmebly works fine locally, but when i try to call it from the network drive, it failes with:
System.Security.SecurityException: That assembly does not allow partially trusted callers.
I have added the following line to the assmebly info:
[assembly: AllowPartiallyTrustedCallers()]
I have also signed the assembly with a strong key.
The issue still persists. Any thoughts?
Regards
Tristan Rhodes
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
The workstations themselves haven't been told to trust the network location or trust assemblies signed with a certain key.
|
|
|
|
|
Ah, i see!
Thank you
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
|
Weeeelllll, what's stopping you from wrapping the Add in a Try/Catch block and handling the problem yourself instead of blindly assuming that evey piece of data your adding/handling is good?? The problem isn't with Microsoft, it's with you.
|
|
|
|
|
Weeeelllll, what's stopping MS from throwing better exceptions? I've got some sample code I can give them on how to do it...
I don't want to have exception handling here as I believe a) that a majority of exceptions should be handled in the presentation layer and b) in this case it was a multi threading problem where we check if a key exists and add it if it does not exist but a second thread would insert causing the first to fail, making the need for explicit exception handling 'unobvious'. After fixing the multi threading problem the exception is fixed and I still don't have exception handling over the add method, won't have either.
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Well, you didn't mention the multithreading issue at all in your first post, so in that case I would have wrapped the add in a lock so no two threads could check for and add data at the same time. In either case, you're still blindly trusting the data you're using and now you just admitted to blindly assuming that every operation you're doing on this data works in a multithreaded environment.
I'm just of the opinion that if you're going to bash someone's code, start with your own.
|
|
|
|
|
I didn't realise this was a code bashing session, until now. You are going into semantics of the example, like I said I do not want to handle errors here (I want them to roll up to the presentation layer), and the lock statement is not the best solution here either. And yes, I am trusting the data I put into this as it is very controllod but I'm not doing it blindly, and I'm not blindly assuming anything because I'm expoecting the exception to be caught in the presentation layer. Now that I have found the problem and fixed it it works perfectly.
Another example: I've de-serialised some data and got an "Argument out of Range" exception, no idea which attribute of the object was out of range and no idea what the acceptable range is, and being Silverlight 3 the MSDN help files pointed me at an article for WPF which is not correct for SL 3 (the article mentioned an int where it was actually an Int16), if the message was "Argument 'asd' is out of range, maximum value is '32767'" it probably would have shaved 3 hours off my debugging.
I'm of the opinion that if you are going to suggest solutions make sure you understand the problem.
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Adriaan Davel wrote: if the message was "Argument 'asd' is out of range, maximum value is '32767'" it probably would have shaved 3 hours off my debugging.
And if the object doesn't have a string representation?? Also, how is the exception going to know what the possible values are for a property that doesn't have "values"??
You want the exception to tailor itself to the property it's throw in and that's just not practical. The exception that MS provides works in the widest array of cases possible, where your exception message only works where a property is a value type.
Adriaan Davel wrote: I'm of the opinion that if you are going to suggest solutions make sure you understand the problem
I do understand the problem, and what it would take to get an exception to do what you want.
The point is, if you want a more meaningful message, wrap the property in it's own exception handler and throw a more meaningful message yourself, then catch that exception in your presentation layer.
|
|
|
|
|
Dave Kreskowiak wrote: You want the exception to tailor itself to the property it's throw in and that's just not practical.
The exception will never know about the values, the code throwing the exception will. Surely there is a range validator that says something like if (value < 0 || value > 32767) throw new ArgumentOutRangeException(); which could be if (value < 0 || value > 32676) throw new ArgumentOutOfRangeException(0, 32767);. This has nothing to do with the string representation of an object...
Dave Kreskowiak wrote: You want the exception to tailor itself to the property it's throw in and that's just not practical
Exactly my point, its not practical to add exception handling to every interaction with the framework just to add detail, if the exception is thrown with more detail, it could make our lives much simpler.
Dave Kreskowiak wrote: where your exception message only works where a property is a value type.
Again your are talking about the specific example, I'm not
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
While that might provide useful information in your case, the framework could not guarantee that the key has a meaningful string representation or that the key is not confidential data.
If I ever used a custom object as the key (and that object has no real other reason to override ToString), the message would become 'The key "MyNamespace.MyCustomObject" has already been added to the dictionary', which is at best no better and at worst a little worse than the original error message.
|
|
|
|
|
I think "MyNamespace.MyCustomObject" would have added value because I have a couple of dictionaries and a couple of parralel threads, it would certainly helped to narrow down the possibilities...
As for confidentiality, is any data on a developer machine in debugging mode confidential?
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
'The key "asd" has already been added to dictionary'
How would you recommend that Microsoft's error handler determine whether "asd" contains confidential information, or that the exception string wouldn't get logged in such a way as to compromise it?
|
|
|
|
|
I would guess that a developer machine in debugging mode does not have confidential data on it, if a developer can step through it the confidentiality isn't very high at all, and in this example I struggle to see how a key would contain confidential data as its a reference pointer...
Probably difficult to make the call in this example (other that being in debug mode)
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Adriaan Davel wrote: I would guess that a developer machine in debugging mode does not have confidential data on it
Hmm.... I wonder whether it would be worthwhile to have a SQL library support a connect-string option for whether to report detailed data in its error messages? I don't think the entity which is generating the exception messages has any way of knowing otherwise whether the machine issuing the queries is in debug mode, but adding a connect-string option shouldn't be out of the question. For maximum utility, a 'duplicate record' message should probably identify the table, column, and key values(*). Who knows--maybe such a thing already exists?
(*) Key values would have a high likelihood of holding confidential data, so they certainly should not be included unencrypted in error reports outside of debug contexts; to avoid parsing problems, they should probably be character-escaped pretty severely, if not base-64 encoded. It may be useful in some contexts to also provide an option for encrypting such data, though I'm not sure what implementation would be best.
|
|
|
|
|
supercat9 wrote: Hmm.... I wonder whether it would be worthwhile to have a SQL library support a connect-string option for whether to report detailed data in its error messages
Yeah, something like that could work for SQL. SQL would probably not know if the connection is in debug mode so something like that would be required (or something like SET DEBUG_MESSAGE_DETAIL ON;), but for the .Net Framework there should be something like if (DEBUG) throw new ExceptionWithDetail(); else throw new Exception();, not sure if that will add significant code overhead though, or if we can get a SDK version of the framework that throws with detail but a "run time" version that throws without... (Or maybe inside the exception class collect info or not based on the DEBUG status)
supercat9 wrote: Key values would have a high likelihood of holding confidential data
Not sure if I agree with you fully on that but that is a matter of design, and can in some cases contain confidential data. I prefer to use and IDENTITY column or a GUID for keys (PRIMARY or FOREIGN), but Business Keys like Credit Card number will be confidential, so yeah, its not a simple thing to do but will have huge benefits for us coders and debuggers...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Adriaan Davel wrote: but for the .Net Framework there should be something like if (DEBUG) throw new ExceptionWithDetail(); else throw new Exception();
For best results, I think the server would have to know about the exception detail, since the server is responsible for generating the message. On the other hand, it might be possible to put a wrapper around the SQL object that would log its state (command string, parameters, etc.) immediately before the query, catch any exceptions, and wrap the exceptions in a package including the pre-query state. That wouldn't be as helpful as having the server adding the detail (since it wouldn't necessarily say which part of a multi-part query failed) but it might help somewhat.
|
|
|
|
|
mmmm, interesting idea, think I'll do that right now in our solution... Not bad for a second prize 
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
There seems to be hope! I have just gotten a System.ArgumentNullException in a LINQ call and the message is: Value cannot be null.
Parameter name: source Great! Now to fix it!
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
