Year 12s: what will be the first way you research your future options? >>

Visual Basic Files handling

Hi TSR,

I have a couple questions regarding File Handling in Visual Basic.

What does appending a file mean?
What is the difference between a binary file and a text file?
What does EOF mean when using text files?
How do Try Catch statements prevent errors in files handling?
How do While statements prevent errors in file handling?

Any help will be much appreciated, thank you.

Reply 1

Trefonix

1) I believe appending a file adds onto the end instead of overwriting existing data
2) A text file contains readable text in the form of ASCII or UNICODE characters so like .txt and .rtf etc, whereas binary files (think .exe, etc.) are stored as unintelligible binary data
3) EOF is a boolean function which represents whether you are at the end of the file you are accessing
4) Try/Catch do not prevent errors, rather prevent them from crashing the program. It allows you to add the error to say, a log file and then continue with the operation of the program
5) While statements could be used in conjunction with EOF to prevent trying to access data that doesn't exist in a text file.

Reply 2

winterscoming

The word "append" simply means "add to the end of"

All files are binary files. A text file is a special type of binary file whose contents can be interpreted using a plain text encoding such as ASCII or Unicode.

EOF simply means end-of-file when attempting to read a file as text. You'll only see 'EOF' in VB.NET if you attempt to read one character at a time. At the lowest-level it's represented by a numeric value of -1. EOF is returned when you attempt to read or peek past-the-end of a file; obviously there's no data to read, so when the attempt is made -1 is the "sentinel" value indicating that there's no more data.

Try...catch statements do not prevent errors. try..catch statements allow you to catch errors when they're thrown, but they do not prevent the errors from occurring

While statements do not prevent errors either. If an error is thrown, then you'd still need a try..catch to pick up the error. Or alternatively, you might consider adding an 'if' check to make sure that there are no errors before/after attempting to read.

Errors should be expected when reading from a file - the key is not to prevent them, but to handle them gracefully. How you handle the error depends entirely on the error, when/how it occurs, and the expected format of the file

(edited 5 years ago)

Reply 3

Tootles

Original post by Yodalam

•

Adding to the end of the file.

•

Binary files are handled differently, so things like BEL, LF, CR, aren't treates like characters or end-of-line or end-of-file markers.

•

A file is a stream of bytes, and EOF is the end-of-file marker. When that character is encountered, that's where the language considers the file to end. Think of it like a tape, with the EOF being the leader at the end, that says "hey I'm here but there's no more data coming".

•

Try/catch is exception handling. For example if you want to open a file and it's not there, it'll throw an exception, which whill bomb the program - but if you try it instead, and the exception is thrown, you can catch it and tell the system what to do. Eg if you try to load a file that's not there, you catch the exception and either cancel loading the file, or create it.

•

While loops are irrelevant to file handling.

Reply 4

Yodalam

Hi,

Thank you for your replies. They all really helped. I just have one quick question about Visual Studio .net

What do Data structures do and how do they "help" the code or make it easier?

Thanks for your help!!!

Reply 5

winterscoming

Original post by Yodalam

Data structures are tools for grouping multiple items of data together. There are a lot of different kinds of data structures which can be useful in different ways to each other. Although its usefulness depends upon choosing the right data structure for a specific problem.

They're useful/helpful in any scenario where you're dealing with multiple items of data which should be logically related to each other somehow by letting you store all of that related data as a single 'object'. The language has a few basic building-blocks built in to the language itself which can be used for creating groupings of data - such as Classes, Structures and Arrays. (Also, technically a string is a data structure too - under-the-hood a string is an array of characters).

Classes, structures and arrays are the tip of the iceberg however - those on their own can be fairly limiting (for example, arrays cannot be automatically resized, and plain classes which only contain data can't have extra fields added automatically).

There are more advanced data structures in the .NET Framework libraries such as List, Dictionary, HashSet and Queue, although all of these have been created by Microsoft from those 'building block' structures which I've just mentioned (classes/arrays/etc). These are more complex and more dynamic in nature; they have a lot of logic sitting underneath them to take care of the work required to overcome limitations of the "built-in" data structures - e.g. the .NET library "List" type can be treated exactly like an array, except Microsoft have already written a load of code for you which allows you to dynamically add data on to the end without needing to write all that logic yourself. Those advanced data structures are a mix of data and methods (i.e. they have behaviour as well as data)

Otherwise, data structures are only useful if you choose an appropriate tool for the job. For example, if you want to represent a 'record' of a real-world 'thing' like a Person or a Car which has lots of different kinds of attributes, then it'd make sense to create a Person class or Car class with different fields which have different types (e.g. a string field, an int field, a boolean field, etc.).

For example Person Name, Person age, Person phone number. Or Car model, Car manufacturer, Car registration, etc. -- those would make sense as fields in a class because your program can then simply deal with "Person" or "Car" objects rather than needing lots of scattered/unrelated variables.

Alternatively, if you'd been trying to gather together a collection of data which all means the same 'thing', such as a collection of names, or a collection of numeric measurements, then it could make more sense to put those into an 'Enumerable' data structure like an array or List. An enumerable structure is a structure in which data items can be counted -- so you can use any enumerable structure like an array, list or dictionary to repeatedly 'step through' from beginning to end using a loop.

Also you can combine data structures together to build up complex 'nested heirarchies' of data - e.g. a List can contain Person or Car objects. Alternatively, a Class could contain a List of something, or a List-of-Lists-of-Classes, etc.

Generally speaking, the most important data structures in VB.NET are String, Class, List and Dictionary. If you can use those 4, then that probably covers 99% of the things you're ever likely to do with data structures.
(You should always prefer a List instead of an array because a List mostly only offers advantages over an array. Generally speaking, there aren't really any particularly good 'use cases' for a plain array unless you're trying to do something very low-level that the .NET framework doesn't already solve for you).

Also, it is entirely possible to use an inappropriate data structure for a problem.
For example, instead of a 'Person' class or a 'Car' class, there's nothing technically preventing you from treating an Array or List as a way of representing a Person or Car - this would create other problems that you'd need to solve in code. For example, you could create a List-of-strings, but then you wouldn't be able to specify different 'field' data types nor would you be able to specify names for those fields either, so there'd be a need to keep track of which field is at which position, and a need to keep converting the data - it'd get really ugly/messy but it shows what kinds of problems arise if you make a bad choice when picking a data structure to use.