Monthly Archives: July 2008

Very Cool VS2008 Add In

0
Posted by admin on July 25, 2008 – 3:46 am
Filed under .NET, Utilities, VB Feng Shui

I’ve always been a big fan of the MZTools addin for VB6, so it was a little disappointing, if not understandable, that for his .NET foray, he’s wanting to get paid a little something for it.

Not that that’s bad, I just haven’t been able to commit to MZTools for .NET just yet.

In the meantime, I stumbled across a very slick little VS addin called DPack.

It’s actually a small set of different addins. Doesn’t look like you get the source, which is unfortunate, but the features are pretty slick, plus they work in VB, C++ and even C# and Ruby.

The Code Browser alone is worth the download. With one keystroke, you get a window like this:

image

It’s nicely sorted, browsable, and with one other click, takes you directly to the given code element. Even better, you can assign direct keystrokes to filter only methods, classes, properties, etc. By default, ALT-M shows just the methods in the current file, for instance. Reminds me of the old F2 (Function list) key that used to be in older VB’s. I missed that key<sob>.

Also particularly nice is the “Surround Selection With…” feature. You can’t customize the surrounding text but they give you the most common items (surround with TRY CATCH, FOR NEXT, DO WHILE, REGION, etc, etc.), so that’s not too bad.

It seems very quick and stable. And the best part is, it’s completely free!

Compressing Memory Streams

0
Posted by admin on July 19, 2008 – 4:09 am
Filed under Uncategorized

One thing that has definitely taken some getting used to (for me anyway) in VB.NET is the whole concept of streams.

I like the idea, generally, but I was working through some code to stream debugging info into a resource in an already compiled EXE file when I ran into a problem with decompressing the resource data.

It just wouldn’t decompress properly.

After backtracking and puzzling over it, I discovered that the problem was actually in the compression phase.

   Private Function pCompressStream(ByVal UncompressedStream As MemoryStream) As MemoryStream
      Dim CompressedStream As New System.IO.MemoryStream()
      Using GZip As New System.IO.Compression.GZipStream(CompressedStream, System.IO.Compression.CompressionMode.Compress)
         GZip.Write(UncompressedStream.ToArray, 0, UncompressedStream.Length)
      End Using
      Return CompressedStream
   End Function

Note the Dim GZip line? If you look at the overloads, there’s a possible 3’rd option, LeaveOpen. It defaults to false.

From what I can tell, if you connect a GZipStream up to a FileStream, there’s no need for this parameter. When the GZip closes, the file is closed and on you go.

But, with MemoryStreams, it’s quite unlikely that you’d want to close the resulting output memory stream after zipping data into it.

But that’s exactly what happens if you don’t set LeaveOpen to True.

What’s worse. You need to Close the GZipStream before reading that MemoryStream(either by using a USING block as I have, or by calling Close directly). If you don’t, garbage collection might not happen for some time and the final data in the internal GZip buffers won’t get written to your memory stream, resulting in only partial compressed data, which definitely won’t decompress properly!

All this is likely old hat to grizzled .NET heads, but if you’re like me and coming from an extensive VB6/assembler background, it can certainly causing some headscratching for a bit.