You cannot call Form.Close while the form is being loaded. If you really need to exit the application before the form is loaded, use Application.Exit. Once the form is loaded, Form.Close is okay to call but won't work (due to bugs in the message pump, apparently) if exceptions were thrown in the UI thread while the form was loading. Instead, call Application.Exit in the event this problem occurs. Otherwise, calling Form.Close on the main application window will close the Form and continue with any statements in the Main entry point.
You can't call it in the constructor, either. You should read about Windows Forms programming in the .NET Framework SDK. Some previous experience with Win32 and the Windows Management APIs would be helpful with understanding the message pump. In this case, however, the application pump hasn't started. See the line:
This is actually broken down to something similar to the following when compiled:
FCMain form = new FCMain();
Therefore, you should throw an exception from your constructor and handle put a try/catch around the statement above. This will not, however, catch other exceptions unless a SystemException is thrown that causes the main form to crash and returns execution to the entry point.
A better design, however, is to move whatever code causes the need to exit out of the FCMain form's constructor and put it in the entry point (or a method that the entry point calls).
Ah, I see.
The problem is that when you use Form.Show(), it creates a global form, not a child form.
You either need to set the Parent property manually (which will also put the second form "into" the first form visually) or create a modal form using Form.ShowDialog().
What happens now when version 2.0 tries to read files written using version 1.0 is that an exception is thrown. What is the most elegant way to handle this? Am I forced to implement ISerializable and do all member serialization myself?
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
To upgrade a serialized document, extend SerializationBinder and override BindToType to bind one version of a Type (passed as a string so you don't have to load older assemblies) to the new Type in your assemblies. See the documentation for the SerializationBinder for more information. You assign this to the IFormatter.Binder property of your formatter, like the SoapFormatter, before deserializing.
On that note, if you're serializing Types for .NET Remoting, you can set the includeVersions to false (either via the .config or the Properties for the formatter sink) so that versions aren't included when serializing an object graph to send across application boundaries.
There was a discussion not long ago about GDI+ squishing characters together at the end of a sentance when NoWrap was used (or a couple other conditions were true). This lead to a topic on MSDN about why it does that and the proper StringFormat to use to eliminate that (StringFormat.GenericTypographic). Try to use the same flags as that if possible.
As far as spaces appearing between letters, this is fairly odd. I've never seen this when drawing my own strings and have never seen anything documented to even control this. Either the text you're passing has spaces (inproper Unicode string?) or the font you're using has some issues. Try a different one and see.
The latest programs use only one process for several application instances. An example is Microsoft Word. When you run it for the first time it creates a process and an empty document. When you run the executable for the second time (while first instance still running) then it doesn’t create a new process. It tells somehow to the first process to create just a new empty document. In this manner the program uses lower resources. How to implement it under .NET?
Is there some reading on how to organize the initial ideas, for a fairly large software (a graphics software, estimated to take about six months). I feel at loss, not having a computer science background.
Last Visit: 31-Dec-99 18:00 Last Update: 1-Oct-23 19:11