If the OS supports it, a user can switch to the Thumbnail view. Other than that, the two derivatives of FileDialog (OpenFileDialog and SaveFileDialog) cannot easily be modified. In fact, this is a major problem that many people have faced. These two dialog classes encapsulate the OPENFILENAME struct and the GetOpenFileName and SaveOpenFileName Win32 functions. In order to customize dialogs using the struct, you have to provide a Dialog resource - a Win32 resource, not a .NET resource. This can be very difficult even with native applications.
The typical solution is to make your own form and use various controls for the tree and list views. Another option is to make a mixed mode Managed C++ class that can use dialog resources and encapsulate all this in a .NET class that you can use from a different .NET language like C#.
Thanks for the prompt response and for the link. The article in that link was well written and worked fine for me.
My GOAL is to set up a webpage through which a user should be able to upload image files and by clicking "Upload" should be able to send it directly into my SQL Server database.
For a start this article was really good. Me being new to this field I would like to split my goal (which to me is a complicated one) into several small parts and start working on each.
These were the steps I could think off:
1. Learn how to upload files (onto a local machine itself)
2. Try uploading files into the SQL Server (remote) database instead of the local machine.
3. If there should be any difference in the loading process between regular text files and image files, what should be done to upload image files?
4. Re-arrange images to set width and height without distortion.
Am I in the right direction?....PLEASE suggest any other articles that could help me in this path.
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.