VB.NET and VB 2005

Copying An Item Between ListViews

Ged Mead — Tue, 09 Jun 2009 09:44:00 GMT

I've always found ListViews quite fascinating. Slightly confusing sometimes, but fascinating nevertheless.

As I have often been heard to say, it's the little Gotchas that'll get ya. Take, for instance, the subject of this blog - copying an item between ListViews. The scenario is that you let the user click on an item in ListView1 and if they want this item copied to ListView2, they hit a button.

Now, you would probably think that all you need to do is identify the currently selected item and add it straight to the second ListView. Something like:

Code Copy

ListView2.Items.Add(ListView1.SelectedItems(0))

But if you do try this, you will get an error.

The text of the error message pretty much says it all. What you have to do (assuming that you aren't prepared to remove the item from the original ListView) is to clone it. You will then be allowed to add the clone to the second ListView.

Although the cloning isn't difficult, you do have to be aware of the need to cast the selected item to ListViewItem if you have Option Strict On. To be honest, I found this a bit strange at first. If I lift a ListViewItem from a ListView, I didn't expect to have to cast it to what it is - i.e a ListViewItem.

I'm not entirely sure why this occurs and wonder if the underlying reason for this is that the ListViewItem is stored in the SelectedItems collection of the ListView as a generic object. Anyway, Casting it back to a ListViewItem at the point where the cloning takes place, fixes this without any problem.

This code works well:

Code Copy

If ListView1.SelectedItems.Count > 0 Then
    Dim lvi As New ListViewItem
    lvi = ListView1.SelectedItems(0)
    Dim lvi2 As New ListViewItem
    lvi2 = CType(lvi.Clone, ListViewItem)
    ListView2.Items.Add(lvi2)
End If

You'll have noticed that I built in a test to ensure that an item is currently selected. It's an easy thing to forget and is sure to bring your app to a grinding halt before long if you don't build this in.

You can see where I have cast the selected item (aka lvi) to ListViewItem in Line 5. Intriguingly, casting to ListViewItem in the third line of code, e.g.

Code Copy

lvi = CType(ListView1.SelectedItems(0), ListViewItem)

doesn't cut it.

Removing Double Quotes from a Text File

Ged Mead — Tue, 09 Jun 2009 09:35:00 GMT

Sometimes you don't have control over how the data is saved to a text file. For instance, some items might be saved with quotation marks around words or phrases. If you want to read the file but not show these marks then you'll need a way to remove them.

Like a lot of things, it's actually very easy when you know how. You can use the built-in Replace function of the String class, replacing the marks as you find them. The trick though (and to my mind, the less than totally intuitive bit) is knowing how many quotation marks to use in the first argument of the Replace method's parameters. This is the 'OldChar' parameter, i.e the one you want to replace.

You would think, wouldn't you, that you could put a Quotation Mark inside a pair of Quotation Marks like this:-

Code Copy

MyString.Replace(""", "")

But if you try that, you will find that it doesn't work. What you actually have to do is include a second Quotation Mark inside the outside ones. In other words, you need four Quotation Marks in a row.

Code Copy

MyString.Replace("""", "")

It's only a tiny change, but it will move your mental state from annoyed confusion to enlightened contentment. Or something like that, anyway.

So putting this together with code that reads from a file and displays the result (minus Quotation Marks) in a ListBox, you have:

Code Copy

Private Sub RemoveQuotes(ByVal filename As String, ByVal target As ListBox)
        '  A StreamReader to fetch the data
        Dim sr As New IO.StreamReader(filename)
        '  A string to hold each line as it is read
        Dim line As String = String.Empty

        ' Read from the file
        ' As long as there is something left to read
        Do While sr.Peek <> -1
            ' Replace the Quotation Marks with Nothing
            line = sr.ReadLine.Replace("""", "")

            ' Add edited text to a ListBox
            target.Items.Add(line)
        Loop

        '  Tidy up when finished
        sr.Close()
        sr = Nothing
End Sub

If you prefer your code to be broken down into clearer steps, you could do this instead:

Code Copy

    Private Sub RemoveQuotes(ByVal filename As String, ByVal target As ListBox)
        '  A StreamReader to fetch the data
        Dim sr As New IO.StreamReader(filename)
        '  A string to hold each line as it is read
        Dim line As String = String.Empty

        ' Read from the file
        ' As long as there is something left to read
        Do While sr.Peek <> -1
            '  Read the next line
            line = sr.ReadLine

            ' Replace the Quotation Marks with Nothing
        line = line.Replace("""", "")

            ' Add edited text to a ListBox
            target.Items.Add(line)
        Loop

        '  Tidy up when finished
        sr.Close()
        sr = Nothing
    End Sub

Either way, your quotation marks will be history.

Restricting TextBox Input

Ged Mead — Tue, 09 Jun 2009 09:28:00 GMT

This is a question that seems to come up a lot in the forums:- How can I restrict the TextBox input to numerals, or only a single occurrence of a decimal point, or some other restriction?

As ever, there are several approaches. If the restriction is something basic, such as numerals only then the easy approach is to use the KeyPress event. What you can do is stop the character from appearing in the TextBox, test to see if it is allowable and, if it is, then allow it to continue.

Letters Only
To take an example which only allows letters of the alphabet, it would look like this:

    Private Sub TextBox1_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox1.KeyPress
        e.Handled = True
 
        If e.KeyChar Like "[A-z]" Then e.Handled = False
 
    End Sub

In this snippet, it is the e.Handled = True which blocks the input temporarily. The next line assesses whether the key press is a letter of the alphabet*, either lower or upper case, and if it is then the handled setting is reversed. This allows the key press to be passed to the TextBox display. If it fails the test, the block on this key press remains.

* Depending on your locale and keyboard, some other keys are allowed. These include symbols that are used in combination with characters in some languages, such as accents. In most cases this is the behaviour you will want.

Specific Keys
Sometimes you may want to allow certain keys. A common situation is where you will let the user use the Backspace to correct an error when inputting:

    Private Sub TextBox2_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox2.KeyPress
        e.Handled = True
 
        If e.KeyChar Like "[A-z]" _
        Or e.KeyChar = Chr(&H8) Then
            e.Handled = False
        End If
 
    End Sub

In this case, it is the Chr(&H8) which identifies and allows the Backspace.

Numbers Only
Another common requirement is to restrict input to numerals. Of the several possible approaches, using IsNumeric is one of the most straightforward:

    Private Sub TextBox3_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox3.KeyPress
        e.Handled = True
        If IsNumeric(e.KeyChar) Then e.Handled = False
    End Sub

Sometimes that is too restrictive though. What happens if you want to allow the user to enter decimal points or (depending on their locale) commas to break up large numbers? Allowing these individual characters is simple, but there is another potential catch as we will see in a moment:

    Private Sub TextBox4_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox4.KeyPress
        e.Handled = True
        If IsNumeric(e.KeyChar) _
        Or e.KeyChar = "." _
        Or e.KeyChar = "," Then
            e.Handled = False
        End If
    End Sub

Only One Decimal Point
In most cases where users are inputting numeric values you will want to restrict them to a single decimal point. The code above will allow multiple entries. Again, there are several solutions, but the following one will usually do the job:

    Private Sub TextBox5_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox5.KeyPress
        e.Handled = True
        If e.KeyChar <> "." Then
            If IsNumeric(e.KeyChar) Then e.Handled = False ' 
        ElseIf TextBox5.Text.Contains(".") Then
            MessageBox.Show("Only one decimal point allowed")
        Else
            e.Handled = False
        End If
    End Sub

Command Keys
If you use any of the previous methods, you will be able to control the standard input keys. But there is another group of keys - Command keys - which won't be excluded by the use of the e.Handled approach. These include such keys as Home, End, Tab, and so on. You may risk alienating your users by excluding these, but there may be times when it is reasonable to do so, in which case you'll need to know how.

A good way is to intercept the message at the window level and you can do this by overriding the ProcessCmdKey function. Here's how:

Create a new class which inherits from the basic TextBox. Override the ProcessCmdKey function and test for the currently pressed key in a similar way to that used in the earlier examples. If the key is one you want to suppress then you return True and the Windows message pump will ignore it.

The following code will be all you need:

Public Class CustomTextBox
 
    Inherits System.Windows.Forms.TextBox
 
    Sub New()
        Me.BackColor = Color.Azure
    End Sub
 
    Protected Overrides Function ProcessCmdKey(ByRef msg As System.Windows.Forms.Message, ByVal keyData As System.Windows.Forms.Keys) As Boolean
 
        ' Declare a variable of type Keys enumeration 
        ' named keyPressed. 
        ' Cast the msg's WParam as a KeyEnum value 
        ' and assign it to the keyPressed variable. 
 
        Dim keyPressed As Keys = CType(msg.WParam.ToInt32(), Keys)
 
        ' Process the key that is pressed. 
        '  If keyPressed = Keys.Home Or keyPressed = Keys.End Then Return True
        If keyPressed = Keys.Tab Then Return True
 
        ' Return the Command key message
        Return MyBase.ProcessCmdKey(msg, keyData)
 
    End Function
 
End Class

The light blue back color is simply to make this sub-classed TextBox look slightly different from the default one for demo purposes, but of course is not a key part of the key checking functionality. As you can see, my example blocks the Tab key. You can add or replace other keys, such as Home and End.

Multiple Options
Handling the KeyPress is fine if you only have a few TextBoxes for which you are controlling input. If there are going to be a lot of them throughout your application, or if you have different input rules for several TextBoxes, then again it may be worth your while to create your own inherited version.

The following example deals with some of the previous scenarios, but allows the input rule to be selected from an enumeration of choices. The choices used here remain basic, but of course you can expand this idea much further.

Here is the code:

Public Class RestrictedTextBox
    Inherits System.Windows.Forms.TextBox
 
    Enum RestrictionCategory
 
        NoRestriction
        NumeralsOnly
        LettersOnly
        AlphanumericOnly
 
    End Enum
 
    Private _allowedKeys As RestrictionCategory
 
 
    Property AllowedKeys() As RestrictionCategory
 
        Get
            Return _allowedKeys
        End Get
 
        Set(ByVal Value As RestrictionCategory)
            Select Case Value
                Case 1 To 3 ' One of the enum choices 
                    _allowedKeys = Value
                Case Else ' No restriction
                    _allowedKeys = 0
            End Select
 
        End Set
 
    End Property
 
 
    Protected Overrides Sub OnKeyPress(ByVal e As KeyPressEventArgs)
 
        MyBase.OnKeyPress(e)
 
        '  Test whether key is allowed, based on the current choice
        '  from the enum
 
        Select Case _allowedKeys
 
            Case 1 'Numerals only 
 
                If IsNumeric(e.KeyChar) Then
                    Exit Sub
                Else
                    e.Handled = True
                End If
 
            Case 2  ' Letters Only
 
                If e.KeyChar Like "[A-z]" Then
                    Exit Sub
                Else
                    e.Handled = True
                End If
 
            Case 3  ' Alphanumeric
                If e.KeyChar Like "[A-z]" _
                Or IsNumeric(e.KeyChar) Then
                    Exit Sub
                Else
                    e.Handled = True
                End If
 
        End Select
 
    End Sub
 
End Class

The key areas are the enumeration which is called RestrictionCategory. These are automatically assigned values from 0 to 3. The Property AllowedKeys and its backing Field carry out the standard roles of a Property, the user being able to set the AllowedKeys property in code. (You could improve this by having the property appear in the Properties Window).

The core of this class is the overridden OnKeyPress method. This checks for the chosen enumeration and then either allows or applies the blocking filter to the currently pressed key. This works in a very similar way to the individual KeyPress approach used in the earlier examples.

By default, all keys will be allowed and to set the enumeration of your choice, you simply include code similar to the following somewhere appropriate in your form (I've used the Form Load event for my example):

  Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        Me.RestrictedTextBox1.AllowedKeys = RestrictedTextBox.RestrictionCategory.NumeralsOnly
 
    End Sub

Summary
I think that a combination or extension of any of the above approaches will enable you to control exactly what you will allow the user to input into a TextBox.

My Blogs Are Moving to New Site

Ged Mead — Mon, 08 Dec 2008 16:13:00 GMT

VBCity will be looking very different soon, as we change to the new Community Server based model. In advance of that change, our blogs are moving to a new area.

From now on, you can view my latest blogs both here and at the new site here. Once the new site is fully up and running, all new blog items will be posted on the new area only.

All previous blogs from VBCity Bloggers will still be available and hopefully will continue to rank highly in search engine results.

How To Get the Icon from an Application

Ged Mead — Thu, 27 Nov 2008 18:00:00 GMT

This question comes up every so often in the forums and it's one of those things that you'd think should be easy, but actually isn't. Well, it isn't until you know how - like most things in developer land. The question is usually something along the lines of "How can I grab the icon from an MS Word file?" The application may not necessarily be MS Word, but the that's the general thrust of it.

The only approach I have successfully used in this kind of scenario is the SHGetFileInfo API*. This API will grab the icon from an application.

Here's the way I do it: First, Import Runtime.InteropServices into your Windows Form.

Code Copy

Imports System.Runtime.InteropServices

Next, the API code, which goes at the top of the form, outside of any procedures:

Code Copy

    Private Structure SHFILEINFO
        Public hIcon As IntPtr
        Public iIcon As Integer
        Public dwAttributes As Integer
        <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=260)> _
        Public szDisplayName As String
        <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=80)> _
        Public szTypeName As String
    End Structure

    Private Declare Auto Function SHGetFileInfo Lib "shell32.dll" _
            (ByVal pszPath As String, _
             ByVal dwFileAttributes As Integer, _
             ByRef psfi As SHFILEINFO, _
             ByVal cbFileInfo As Integer, _
             ByVal uFlags As Integer) As IntPtr
    Dim hImgSmall As IntPtr 'The handle to the system image list.
    Private Const SHGFI_ICON As Long = &H100
    Private Const SHGFI_SMALLICON As Long = &H1

Note the two Constants at the end there being declared as Long. You'll usually find you have to tweak old API code to fix these kind of lines if you have Option Strict On.

To demonstrate this API in action, here is how I've structured it:

I have added a button (btnSelectFile) to the Form.
When this button is clicked, an OpenFileDialog is created to allow the user to select a file.
Once a file has been selected, the file name is passed to a function that will dig out the icon for that file type and pass it back.
For demo purposes, the Form's default icon will be replaced with this selected one.

Here is the code in the function that grabs the icon:

Code Copy

Function GetIcon(ByVal filename As String) As Icon
        Dim shinfo As SHFILEINFO
        shinfo = New SHFILEINFO

        'Get the small icon.
        hImgSmall = SHGetFileInfo(filename, 0, shinfo, _
          Marshal.SizeOf(shinfo), _
          SHGFI_ICON Or SHGFI_SMALLICON)

        Return System.Drawing.Icon.FromHandle(shinfo.hIcon)

End Function

And here is that function being called from a Button Click, the icon then being shown as the Form's icon:

Code Copy

  Private Sub btnSelectFile_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSelectFile.Click
        Dim ofd As New OpenFileDialog

        If ofd.ShowDialog = Windows.Forms.DialogResult.OK Then Me.Icon = GetIcon(ofd.FileName)

End Sub

That's pretty much all there is to it, if you are happy to plonk the icon on the form like that. But in most cases you'll probably want something a bit more reusable. One easy way to store the grabbed icon is to put it in an ImageList.

Assuming that you are only going to deal with one icon at a time, you can do something like this:

Code Copy

Dim myIcons As New ImageList
myIcons.Images.Add(System.Drawing.Icon.FromHandle(shinfo.hIcon))

Now that you have that icon safely stored in the ImageList, you can access the ImageList in the usual way if you want to place the icon image elsewhere. And of course you can change the above code slightly to allow for more than one icon to be added to the ImageList and used as required.

Finally, if you need to switch the icon into Bitmap format you can use the handy ToBitmap method:

Code Copy

Dim bmp As Bitmap = System.Drawing.Icon.FromHandle(shinfo.hIcon).ToBitmap

It is possible then to save the Bitmap by using the Bitmap's Save method. However, I have found this to be a bit hit-and-miss, with it sometimes throwing a generic GDI+ error when I tried to recall it for use by means of the Image.FromFile method.

I hope that if you need to grab an image from an application that you find this article useful.

----------------------------------------------------------------------

* There is the much more hopeful sounding ExtractIcon API which I have used to extract the icon of a currently running VB application, but haven't managed to port the logic over to the kind of file selection scenario described here.

WPF: How To Hide the Minimize and Maximize Buttons

Ged Mead — Wed, 22 Oct 2008 09:17:00 GMT

For some time now, I've been promising myself that one day I will create a list of what I like to think of as "WPF MIA" - those basic elements that I am totally familiar with in WindowsForms, but which somehow seem to have disappeared into thin air in WPF.

In many cases of course the tools are still there; it's just that the name has changed. Here's an example:

In Windows Forms, you can hide the Minimize and Maximize buttons by setting the MinimizeBox or MaximizeBox to False I guess that this is most people's favourite way of doing this. If you dig deeper into the Properties Window though, there is also the FormBorderStyle property.

I used to think that this property was only good for things like changing the border style, say, from 3D to single line. But actually if you choose FixedToolWindow or SizableToolWindow then you automatically get a Form that only has the close button - no Min or Max.

So what about WPF then? Does it have the same properties available?

If you've spent any time on WPF, you'll know that that's really a rhetorical question because you can almost guarantee that things will have changed. Now though you have a WindowStyle property which you can use to set the Window's border style, including showing or hiding the Max and Min buttons. To have those buttons hidden, you need to choose the ToolWindow option.

As far as I know, there isn't a property setting that will hide the individual buttons in in WPF. At first I found this a bit surprising. However, as I've become more familiar with WPF and its ability to morph its Windows into almost any conceivable style and shape, I can see that creating your own Window style is so easy that maybe those properties would have been almost redundant anyway.

How To Navigate Around Your Code in Visual Studio

Ged Mead — Tue, 08 Jul 2008 15:48:00 GMT

One of the things that I've always found a bit frustrating as a project grows larger and larger is that it gets more difficult to navigate backwards and forwards between chunks of code that you've recently accessed.

Now I know that Visual Studio has some built in navigation hot keys:

Ctrl and Minus to go back to the last point,
Ctrl-Shift-Minus to go forward again are the most useful,

but it can still be a bit laborious when you're trying to flit between several sets of code blocks and you don't particularly want to move in a linear or consecutive way.

Step forward that very clever little Add-In (well, not so little really!) CodeSMART. For some reason I'd stopped using it when I upgraded Visual Studios a while back, but when I was looking around for an answer to this problem I remembered that amongst its many little tools is the Code Explorer.

One of the elements included in the Code Explorer window is a history of the last 20 procedures you've visited. So not only can you move backwards and forwards one step at a time, you can of course jump to any of the saved locations just by double clicking on a choice in the list.

It has some smart features (well, it is CodeSmart after all!), one of which is that it greys out any history items from other files - which helps you to very quickly identify those in your current file that you may be looking for.

And best of all? It persists your history list for each individual Visual Studio Solution, so that the next time you access a particular project Code Explorer will be repopulated with the relevant history for that project. How cool is that?

The Code Explorer does have additional features, such as a fast and neat search tool to take you to procedures that match search criteria, together with what's effectively a Favorites store, the Workbench, where you can keep tabs on items you're particularly interested in.

Of course, CodeSMART has a ton of other features and tools, so if you want to check it out you can download a trial version from their website here.

Another Gotcha! - Select Case Using a Range of Integers

Ged Mead — Sun, 06 Jul 2008 17:22:00 GMT

I never cease to be amazed at how many ways you can fool yourself into thinking that your code will do one thing, but in fact it does something completely different. Sometimes the subtlety of the error is so fine that you can spend ages trying to work out the source of the problem and, to make life harder, there's no Exception message to give you a pointer and sometimes even using the debugging tools doesn't lead you straight to it.

I was working on something that kept track of a particular value. If the value was between 31 and 40 then I wanted to display a message. Without thinking too hard about it, I wrote the following code:

Code Copy

Select Case InputValue
            Case 31 - 40
                MessageBox.Show("Invalid Values")
            Case Else
                '  Do something
End Select

So, what do you think? Will this do the job as described?

Actually, no - of course not; otherwise I wouldn't be sat here writing about it, would I? The question is then: What's wrong with it? On the face of it, it seems to check for values between 31 and 40, displaying a message if that case fits. Otherwise, it does something else. But if you were to try this code and enter values between 31 and 40 you wouldn't get to see that MessageBox.

It's one of those Duh! moments as soon as you realise why. Although most of us will have read that as saying "Case 31 to 40" , that isn't how the compiler sees it. Because we are dealing with numbers and because the compiler knows about adding and (in this case most importantly) subtracting .... the compiler reads that as "Case 31 minus 40. So the MessageBox will only appear if a value of -9 is applied to the InputValue variable.

It's not a compilation error, so you don't get any feedback. It's allowable but faulty syntax, so you're not alerted to what is essentially a logic mistake.

So simple when you realise why, but it's another example of those tricky little Gotchas that'll get ya if you don't watch out!

Searching Through Folders to Find File(s)

Ged Mead — Wed, 04 Jun 2008 16:10:00 GMT

I was looking for a task to use as the background task of my recent article on the BackgroundWorker component and decided that I'd use a recursive search through folders. Ironically, I ended up spending about twice as much time on getting the recursive search procedures running correctly than I spent on the main BackgroundWorker code.

As I ended up with three varieties of recursive searches - and found some things that should have worked, but didn't seem to - I thought I'd blog it.

To find a particular file type in folders and sub-folders I used this code:

Code Copy

Sub FileFinder(ByVal dir As String)

        Try

            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith("txt") Then
                    '  pass back progress message
                    Console.WriteLine(fname)
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileFinder(subdir)
            Next
        
        Catch ex As Exception
            MessageBox.Show(ex.Message.ToString)

        End Try
    End Sub

You'll probably have spotted that I used the "EndsWith" function there to test for the tile type I'm interested in. Originally I tried using the SearchPattern parameter of the GetFiles method, but for whatever reason it didn't identify the files for me.

Another little glitch to keep in mind is that there may be some files to which users don't have authorised access. If for example you call the above code and pass in "C:\" as the argument you will probably get one or more "Access Denied" messages via the Exception Handler. Of course, because the exception is being handled, the user can click on the messagebox's OK button and the procedure will continue to run.

Obviously, to avoid the message appearing at all you can just comment out the MessageBox.

If you want to home in on that particular issue and allow access but still want to know if other kinds of problems occur then you can fine tune your structured exception handlers (as of course you should) and include a handler specifically aimed at the access exception:

Code Copy

Catch ioex As System.UnauthorizedAccessException

   ' Access Denied Problem will be handled here

Catch ex As Exception

    ' Other Exceptions will be flagged up to users

    MessageBox.Show(ex.Message.ToString)

Hard coding the file type limits reusability, so a better version would be:

Code Copy

  Sub FileTypeFinder(ByVal dir As String, ByVal FileExt As String)

        Try
            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith(FileExt) Then
                    '  pass back progress message
                    Console.WriteLine(fname)
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileTypeFinder(subdir, FileExt)
            Next

        Catch ioex As System.UnauthorizedAccessException

        Catch ex As Exception
            MessageBox.Show(ex.Message.ToString)

        End Try

    End Sub

The client now passes in the file type as well as the parent folder.

The final version I used was one which recursively searched through folders and subfolder, found files that matched a particular file extension and then searched inside matching files for a particular string. This of course could be a particularly long task in some cases and so a good candidate for the BackgroundWorker.

Code Copy

    Private Sub FileContentFinder(ByVal dir As String, ByVal FileExt As String, _
                                 ByVal TargetText As String)
        Dim rdr As IO.StreamReader

        Try

            ' Display all files in a directory that match file type
            For Each fname As String In IO.Directory.GetFiles(dir)
                If fname.EndsWith(FileExt) Then
                    rdr = New IO.StreamReader(fname)
                    Dim strFileContents As String = rdr.ReadToEnd
                    rdr.Close()
                    rdr = Nothing

                    ' If this file contains the target string, pass back progress message
                    If strFileContents.Contains(TargetText) Then
                        Console.WriteLine(fname)
                    End If
                End If
            Next

            ' A recursive call for all the subdirectories in this directory.
            For Each subdir As String In IO.Directory.GetDirectories(dir)
                FileContentFinder(subdir, FileExt, TargetText)
            Next

        Catch ex As Exception
            MsgBox(ex.Message.ToString)

        End Try

    End Sub

There are many other twists you could use on the above approaches, such as testing against file attributes for dates, for example, or copying files that meet certain criteria.

VB 2005: How To Print With Word Wrapped Lines

Ged Mead — Tue, 08 Apr 2008 17:06:00 GMT

Introduction
Printing can often be a bit of a tricky task in .NET. Some things are more easily resolved than others though.

I saw a post recently that raised a problem that seems to occur fairly regularly: You want to print a large chunk of text to the printer, but VB seems to want to print everything all on one long line - even when this means that a lot of the text will be truncated or "printed" invisibly into thin air!

Fortunately, this is one of the cases where the solution is relatively easy. Essentially, what you do is set a rectangle whose width represents the width of your printed page (or any lesser width you prefer). You then pass this rectangle to the DrawString method and it will obediently print within those boundaries.

Solution
Here's the basic solution:

Code Copy

  Imports System.Drawing.Printing

Public Class frmPrint

    ' The document you will use to print on
    Dim DocPrint As PrintDocument

   ' Set font for printing
        Dim fnt As Font = New Font("Verdana", 12, FontStyle.Regular)

'  The printing is fired with a button click event
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        '  Print the textbox content

        DocPrint = New PrintDocument
        ' A handler for it
        AddHandler DocPrint.PrintPage, AddressOf PrintTheTextBox1

        ' Print the document
        DocPrint.Print()
    End Sub

  '  The procedure that does the printing
  Private Sub PrintTheTextBox1(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF
        PrintRect.Width = 800
        PrintRect.Height = 1000

        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

Yes, But.....
That's OK as far as it goes, but it does suffer from one flaw. When you check your printed page you'll find that the text is stuffed right up at the top left of the paper and each line extends fully across to the very last few millimetres at the right hand side. Now, it may be that paper saving is high on your agenda, in which case you'll be happy. But generally you will probably want a layout that's a bit more generous with its whitespace.

The trouble is that there isn't an overload that allows you to pass in the Rectangle and the start position for the printing. Is that going to stump us? Nah, of course not!

If we go back to the Rectangle itself, there is a constructor overload that allows you to pass in the x and y values as well as the width and height. The x and y values will of course be used as the left and top points respectively of the rectangle as it is positioned on the printed page. So this variation will get the start position, the text line width and text block height all sorted:

Code Copy

Private Sub PrintTheTextBox2(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF(30, 100, 750, 1000)
       '  Assign its Left, Top, Width and Height values

        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

While I was working on that, I remembered that the Rectangle has a useful little method named Offset (something you would normally use when drawing actual rectangles in a graphics based task). However, by using this method and adjusting the values that are passed so that the top left of the rectangle is shunted down and to the right, we can get nearer to the layout we desire. If you chose to use this alternative route, it would look like this:

Code Copy

Dim PrintRect As New RectangleF
        PrintRect.Width = 800
        PrintRect.Height = 1000
        PrintRect.Offset(25, 60)

Show Me The Width
It probably won't have escaped your notice that I very conveniently just happened to know what width and height I needed for the text to span across the page. Many times you will have this information to hand, but if you don't, what do you do then? Answer: You calculate it by querying the PrintDocument's PageSettings, find the width, height and margins and use those. Here's the code:

Code Copy

   Private Sub PrintTheTextBox3(ByVal sender As Object, ByVal e As PrintPageEventArgs)

        'Set a rectangle to bound the  printing
        Dim PrintRect As New RectangleF

        With DocPrint.DefaultPageSettings
            PrintRect.Width = .PaperSize.Width - (.Margins.Left + .Margins.Right)

            PrintRect.Height = .PaperSize.Height

            PrintRect.Offset(.Margins.Left, .Margins.Top)
        End With


        ' Print the text from the TextBox:
        e.Graphics.DrawString(TextBox1.Text, fnt, Brushes.Black, PrintRect)

    End Sub

Summary

Although there are many more tweaks we could add to this approach, I think that the above will cover many common situations. If text trimming at the end of lines is something you need to refine to the nth degree then you should check out the StringFormat class in general and the StringTrimming enumeration in particular. There are several options available there.

Don't forget of course that you may not need to hand code your printing processes at all. There is a free Power Pack available which will print the contents of a form with minimum effort on your part. This will often be all that you need, but if not then at least you now know how to package up a bundle of text and send it to the printer to be laid out in a way that suits your requirements.