Why not just use a jagged array, a.k.a. an array of arrays? When you get Segment (note, all .NET languages use 0-based indexes, not 1-based indexes!) you get an array of 256 elements, whatever they are:
WaveSegment segments = new WaveSegment;
for (int i=0; i<segments.Length; i++)
segments[i] = new WaveSegment;
You can then access them in several ways, including:
I don't know - you used it in your code fragment so I thought I'd reuse it. Maybe I'm using wrong in your context, but the idea is the same. WaveSegment could be anything: a class, struct, enum, or even a delegate! All you're doing is making an array of an array of something (no, I didn't stutter! ). The first line made an array of WaveSegment with 17 elements. In my code fragment, I then created a new array of 256 elements within each of those 17 elements. The second line above merely gets that 256-element array from the first array element from the array with 17 elements.
See Arrays[^] in the C# Language Features reference on MSDN, or more specifically Jagged Arrays[^] for more information.
Glad you solved it, but just for future benefit, the line Console.WriteLine(arrSegmentArray[i].ToString()); is calling ToString on a Int32 array. The default implementation of Array.ToString() (inherited from Object.ToString) is to simply print the namespace-qualified class name.
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).