Scribd
Upload
4 views

complete-reference-vb_net_53

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

complete-reference-vb_net_53

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Streams

Changed Fires on the change of a file or folder. The types of changes include: changes to size,
attributes, security settings, last write, and last access time.
Created Fires on the creation of a file or folder
Deleted Fires on the deletion of a file or folder
Renamed Fires on the renaming of a file or folder
You also need to be careful not to create too many events in the FileSystemWatcher object, a problem that
can arise when a file you are watching is moved to another folder you are also watching. You'll get events for
the "departing files" as well as the "arrival files." For example, moving a file from one location to another
generates a delete event, OnDelete, when the file departs. Then you get an OnCreated event when the file
arrives at its new location.

You also need to be cognizant of the changes other applications make on your files. Backup software changes
the attributes of files. Virus software also has a stake in the file system because it opens files, inspects them,
and then closes them. Products like Open File Manager, which lets backup software back up open files, may
also conflict.

Too many changes in a short time may also cause the object's buffer to overflow. This will cause the object to
lose track of changes in the directory. Memory used by the object is also expensive, because it comes from
nonpaged memory that cannot be swapped out to disk. The key is to keep the buffer as small as possible and
avoid a buffer overflow by refining your operations. This means dropping unnecessary or redundant filters
and subdirectories.

Streams
The previous section covered how we can manage files and folders. Now we will cover the support .NET
provides for getting data into files and getting it out again. This is the crux of I/O, and .NET accomplishes it
with streams.

The .NET Framework defines a base class called Stream that supports the reading and writing of bytes. Any
time that you implement stream I/O functionality, you will inherit, or directly instantiate, objects from the
classes inherited from Stream. The derivatives of Stream can be found in Sytem.IO, System.Net,
System.Security, and System.XML.

Stream is an abstract class and has been extended in a variety of specialized child classes. You can derive
from Stream and build your own classes to support streaming. But you would be hard−pressed to come up
with something that isn't already supported in the base class library (other than soda streams), or that isn't
already earmarked for the next release of the .NET Framework.

The Stream class and its children provide a facility for handling data, blocks of bytes, without having to care
about what happens down in the basement of the operating system. There is no need for you to burden
yourself with the myriad details of how data flows down to metal and across the wire. The various layers
beyond your method calls are dealt with by the CLR and the file system. So perfectly aligned are these classes
with the platform that writing and reading to streams makes you feel guilty for what programmers in the
"Wild West" days of C and Assembly had to go through.

The following classes derive from Stream:

• BufferedStream Reads and writes to other Stream objects. This class can be derived from and
instantiated.

537

You might also like