Thought I'd post this link as it was annoying me and took a little while to find a straight forward explanation.

I've just recently moved over to Windows 7 and decided to go for the 64bit version, using Visual Studio 2008 I find that I can't edit whilst in debug mode.. all something to do with Visual Studio not being a true 64 bit app.

Well this helpful article told me all I needed to do to get this working again, just changing build configuration and adding a new active solution platform of x86.

Full details can be found here, well worth a read:

http://blogs.msdn.com/habibh/archive/2009/10/12/how-to-edit-code-when-debugging-a-64-bit-application.aspx

This has bugged me for ages and I've finally spent 10 minutes finding the solution to it.

I develop lots of custom controls which I will never place on a form at design time, their add-on components that are loaded at runtime and docked in conditionally.  This ended up with Solution bloat meaning every time I first went into a design view of a form Visual Studio went into a fit building up a complete toolbox of things I'd never need.

One simple attribute was all that was needed to stop them being populated in future;

<System.ComponentModel.DesignTimeVisible(False)> _
Public Class MyUserControl ....

Hopefully someone else will find this useful for the future.

Having recently bought a U3 Drive I've got the bug for portable apps.  This unfortunately has jarred with my love of the settings provider provided within .net 2 which insists on storing settings in the Documents and Settings folder structure.

I've done some research into whether it is possible to change this default functionality and as with just about everything in .net there is!

I've taken the time to write this up as a Code Project article available from My Code Project articles.

The article covers creating a general xml settings file that resides in the applications folder, but also includes a class for U3 specific functionality.

I've also produced U3 specific versions of my ThumbGen and MiniCalc applications, available from my U3 Downloads area.

There's one major gripe I have with the VB language.. the With/End With block.  Although it shortens code lines when setting lots of properties I find it harder to read, error prone when moving code around, and very awkward to debug since you can't just select the property and add a watch.

I never use this syntax in my own code, always preferring to have everything in long form, it doesn't increase typing too much with intellisense and we all have fairly large displays these days so line length is less of an issue as well.

So when using code I find on the net or from colleagues the first thing I do is remove with blocks.  Getting fed up with this time consuming but quite dumb task I've created a Visual Studio macro to do it.

As an example, code with a With statement like the following;

    Public Sub AWithExample()
        With Me
            .Text = "Hello"
            .Tag = "This"

            MessageBox.Show(.Text, "Title " & .Text)

            Dim x As String
            x = .Text
        End With
    End Sub

Becomes;

    Public Sub AWithExample()
        Me.Text = "Hello"
        Me.Tag = "This"

        MessageBox.Show(Me.Text, "Title " & Me.Text)

        Dim x As String
        x = Me.Text
    End Sub

The Macro's quite trivial, just create a new macro and add the following code; More...

One thing that seems to be a bit hidden to most developers is that opening files within Visual Studio works the same as opening them within a standard file explorer window in that you can specify the default way of opening a file.

This is particularly useful for forms/user controls in that 90% of the time you'll want to dive straight into the code, not go into the form designer even though Visual Studio defaults to opening the form designer which takes an age if you have lots of controls on your form.

To change the default is easy, this example will illustrate changing a VB form from the designer to the code editor.

• Right click on a form within the Solution Explorer window and select Open With...
• A dialog appears listing applicable editors within Visual Studio you can use.
• Select Microsoft Visual Basic Editor
• Click the Set As Default button.

And that's it, from now on every time you double click on a VB form you'll bring up the code window rather than the designer.

The association is for the whole of Visual Studio, regardless of solution/project loaded.

Another VSI package for you, this time handling common win forms settings.

It provides auto upgrade code for new versions of your application, window size and position loading and saving.
It handles the initial loading of an app as well as closing whilst minimized/maximized.

I'd recommend installing them into a Settings folder under your My Documents\Visual Studio 2005\Code Snippets\Visual Basic\My Code Snippets folder.

You can download the package from my Visual Studio 2005 Tools downloads area.

This isn't something I came up with - I'm not taking credit for it.  I just found it on the net a long time ago and a colleague asked me about it so I thought I'd put it here for future reference.

With VS2005/.net 2 you get the ever so useful my.settings stuff.  This is fine except it's version specific.  When you release a new version of your app it creates a whole new settings file, ignoring the previous one for the old version.

To overcome this put in a new boolean setting, I call mine CallUpgrade, and set it's default value to True.

Then in your form load/get settings sub do the following;

        If My.Settings.CallUpgrade Then
            My.Settings.Upgrade()
            My.Settings.CallUpgrade = False
        End If

Now every time your app load it will look at your current CallUpgrade value, if it's the first time that version's been run it will be true and so the specific My.Settings Upgrade method will run which looks for a previous version and ports the setting values across.  Then setting the CallUpgrade flag to false for future loads to not waste time trying to upgrade the settings.

Simple, a little cludgy on Microsoft's part not to have a more clear solution to it but this does the job.

As you know if you've been keeping up with this blog, I've got rather into my snippets and templates for Visual Studio.

I've followed the msdn examples on how to create vsi packages manually and all is hunky dory with that, but sometimes you just want a quick knock up package and crafting xml, renaming zip files and stuff just seems like too much hassle.

If your into vsi packages check out the Visual Studio Content Installer Power Toys it makes it far easier to create packages.

And if you just want to create code snippets easily then check out the Visual Basic Snippet Editor it has a great ui for creating snippets, specifying parameters and shortcuts and even saving it all as a vsi.

Continuing my sifting through the bits and pieces I've accumulated I present two visual basic code snippets for handling wait cursor functionality within win forms easily.

Again it's a VSI package - once installed you will have two snippets;

• One which goes to a wait cursor then back to default.
• The second one remembers the current cursor, displays the wait cursor then goes back to the previous cursor.

Both are shortcutted beginning wait, so from Visual Studio just type wait? then tab.

You can download the package from my Visual Studio 2005 Tools downloads area.

I'm trying to go through all my bits and pieces and either file, delete or publish them.

Here's a little something I thought I'd share with you, it's a simple GUID Visualizer I created using my Visualizer Template.  It just displays a text box displaying the value in string format of the current guid.  If you've ever tried debugging guids before you'll know that it's not easy, always giving you a misleading empty, which is actually a property of the guid type rather than its actual value.

This is my first add in I've wrapped up into a VSI package (Visual Studio Installer), it's actually quiet easy to do and I might revisit some of my other packages and wrap them up as well.  Unfortunately it requires signing to stop the warning about dangerous code so maybe I'll have to commit to buying a code signing certificate.

You can download the package from my Visual Studio 2005 Tools downloads area.

I'm sure most Visual Studio users have heard of Carlos, he's the man behind MZTools, one of the most useful Visual Studio AddIns around.  I've been working with it since the vb6 days and have converted most of my colleagues to using it as well.

If your into Visual Studio extensibility then this blog is worth a read - as are his regular forum posts, I've certainly learnt a lot from him in the small amount of work I've done in this area.

The blogs available here as html and the rss is here

I've been investigating NUnit recently and was getting frustrated by the amount of repetitive code you had to write for each item you wanted to test, so I wrapped it all up into some helper project and item templates.  Then went a bit further and created a few code snippets to help as well.

I thought I'd make it available to you lot as I'm sure its something everyone sits down and has to write all the time.

The templates/snippets are all for VB.net but I'm sure you could adapt them for C# if you so wished, there seems to be a lot more demonstrations for C# out there anyway so I thought I'd try and even the balance.

You can download the vsi package containing them from my Visual Studio 2005 Tools downloads area.

I submitted my first article to CodeProject today.

It's one of my favourite sites when looking for articles on new areas I haven't dealt with before so I thought i'd share my technique of using custom attributes and reflection in vb.net.  I demonstrate how to use it to read query string parameters easily into fields without all the repetitive code.

Have a read and see what you think

I needed to knock up a small custom debug visualizer for a project I'm working on.  There really easy but I always have to lookup the exact references etc to include which is actually the longest part of the process.

To ease matters next time I spent a little time creating a project template, something I've never done before.  Now when I want a new visualizer I just start a new project based on the template and it's got all the references etc done for me, all I have to do is read the todo messages and replace a few lines to include the functionality I need.

I thought I'd share the visualizer template with you since I'm sure others will have googled this several times over to remember how to do it. 

You can download the vsi package from my Visual Studio 2005 Tools downloads area

I've just had one of those doh! moments so I thought I'd write about it here in case I ever forget it.

I've avoided using the listbox for years and years (since VB5 I think) since it doesn't fill a specified height.

Forced back to a listbox for a bit of owner draw code I want to implement (which is really cool and easy in .net by the way) I was hit by my age old problem.. then a property just jumped out at me, IntegralHeight which is set to true by default, this is the magic little thing I've been looking for which (if set to false) stops the listbox resizing to a multiple of it's item height.  I'm not sure how long this has been here and I feel an idiot for missing it if it was in VB5 but now I know, and I'll use listboxes for more stuff rather than stick with listviews in detail mode.

If you haven't looked into using attributes you really should.  We've all used the serialization ones I'm sure but think about using your own, it's not that difficult, just a simple class with an attribute telling it that it itself is an attribute and where it can be used then a bit of code using reflection techniques to interogate them.

I'm using it as an ORM technique, describing the stored procs to get/save classes and also describing the property to field mappings.  It's early days with my architecture but I'm liking it, for all those simple objects its going to do away with the whole persistence code that we all write over and over.  I've seen lots of other ORM solutions but attributes is my personal choice of where I'm going, it keeps the description with the object rather than in some config file or other complicated solution.  It also means you can carry your class to another project with ease, very little dependency involved as long as you have your ORM persistance class/assembly carried over as well.

Just in case you haven't spotted it yourself have a look at the applications settings improvements in VS 2005.

Earlier versions of VB.net gave you the app.config file which was a god send, but now you don't even have to write all the persistence/retrieval code.  In the properties for whatever visual element you have go to the ApplicationSettings property under Data and you can bind any control/form property to a value in your .config file. 

I use it all the time for form size/position persistance, last entered values, splitter sizing etc.etc. 

Simply superb, theres just no reason for an app not to save user preferences now, it's a 2 minute point and click job.

Had a tricky problem today whilst working on my wallpaper application.

The program resides in the tray and has a settings form that I don't want to really quit the application when closed, just hide the window and still sit in the tray.  The trouble was I wanted to respond to windows shut down requests and actually quit the application, without the following fix my application cancelled the windows shutdown!

After much searching I came across the handy WM_QueryEndSession message.  The code snippet below shows it's use for detecting a true windows shut down rather than just a close of the form.

Private Shared WM_QUERYENDSESSION As Integer = &H11
Private Shared systemShutdown As Boolean = False

Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
    If m.Msg = WM_QUERYENDSESSION Then
        systemShutdown = True
    End If
    ' If this is WM_QUERYENDSESSION, the closing event should be fired in the base WndProc 
    MyBase.WndProc(m)
End Sub 'WndProc 

Private Sub frmMain_Closing(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing
    If Not systemShutdown Then
        Me.Visible = False
        e.Cancel = True
    Else
        e.Cancel = False
    End If
End Sub

It's always a problem giving users settings they can change.. where exactly should you save these... first it was win.ini, then the registry and now it's the users application data folder.

This new place has the advantages that it's user specific and relatively secure and it's easy to see/edit/move to another machine.

.net has Application.UserAppDataPath which returns the current recommended path for application data for this application.  Unfortunately it also appends the current version number of the application, which although good for large applications where versions may change radically, for minor revisions it's annoying in that every new build would effectively loose users settings and they'd have to set it up again (or copy the file)

I've knocked up this simple function that simply removes the version info and returns a path that can then just have your settings file appended to get a consistent path.  Thought I'd share it here for the masses;

Public Function AppSettingsPath() As String
Dim AppPath As String
Dim LastSlash As Int16
AppPath = Application.UserAppDataPath
LastSlash = InStrRev(AppPath, "\")
Return AppPath.Substring(0, LastSlash)
End Function