Monthly Archives: December 2005

Threading for dummies (i.e. me)

Just Rambling

It would be really handy if the compiler could tell when you have written code to access UI components in one of the external thread processes of the BackgroundWorker component, such as DoWork. (Yes, the debugger tells you when you messed up… just not the compiler.)

Luckily at least some of these are caught in runtime.

I will have to write myself a little reminder comment in these methods NO UI ACCESS HERE, DUMM-DUMM! I think that I will get over this very quickly though., as I get more and more used to working with asynch processes.

You, too, can write asynch processes (almost) easily in VS2005 now with the BackgroundWorker component. But you still have to know what you are doing and pay attention. You don’t need to know threading inside and out – but have an awareness of it.



Don’t Forget: www.acehaid.org

Finally gave in and bought a new printer

Tools

I have an old HP Laserjet 4si that I bought a looooooong time ago. I think the retail price was $5000 and I paid about $3500. I can only remember that it was when I was living with a certain guy and we broke up when I was 33. So it is at least 11 years old! It has really been a die-hard and has MORE than earned it’s keep, even with having to lug this 125 lb beast through three household moves.

It actually still performs like a trooper but it’s no longer 100% dependable. I get paper jams that drive me batty when I have to print out lengthy reports – whether it’s the 100 and 200 page reports I have to print for a client  about 10 times a month or even just a 10 page document. I had the printer serviced last winter and started using better quality paper in it. The jams are back again though and yesterday, under duress, I had to send out a 100 page report with pale streaks through it (which the client was able fade out when they made their photocopies). Apparently this is either the (not very old) fuser or something suddenly wrong with the print cartridge causing the streakes. Solvable, but dumping more money into it.

So I gave in and bought its’ replacement today. A 38 pound, $400 (after rebate) faster (22ppm vs 16 ppm max) LaserJet 1320t. It also does duplex printing (which I occasionally would love to have). I never needed the network capabilities so I don’t have to pay for that now. And the paper trays hold 250 pages instead of 500. No problem there for me.

It’s a hard thing to do. I always have better things to spend my money on, but I realized that at this point, it will cost me a good $100+/year to keep it going in addition to the aggravation of those occasional paper jams which are very costly in their own way.

Don’t Forget: www.acehaid.org

Using Blocks are new to VB’ers, what are the rules?

dotNET

Using blocks are new to us VB developers. I get the basic concept – it’s cleaner than try/catch/finally blocks when all you are doing is disposing an object and it’s super great when dealing with unmanaged resources and good ol’ SqlConnections.

But the intricacies of using it are a little less obvious. Luckily, this code construct has been around in C# (and I will guess C++??) so we can learn from those folks.

I was trying to find a better way to deal with a file stream and memory stream today. Porting some code over from vs2003 to vs2005, the compiler was moaning about the following code block (I am only writing it loosely here…) where I am passing in a file name, opening up the file into a streamReader and then doing something to the streamreader and then closing both objects at the end. Maybe it wasn’t written perfectly to begin with, but the compiler issue was a new one.

dim fs as new FileStream(myfilename,FileMode.Open)
dim sr as new StreamReader

Try
   myStreamReader=new StreamReader(fs)

  … do some stuff

Catch exS as IOException
 … do something
Catch ex as Exception
 .. do something
Finally
   If  Not fs is nothing then
      fs .Close
  EndIf
  If Not sr is Nothing then
     sr.Close
  End If
End Try

So when I ported this to VS2005, the compiler was not happy about accessing the streamReader in the Finally block because it was possible that no value would be assigned and I’d get a null ref exception (on the bold red line.)

I knew that I could get rid of those Close methods with a using block but was not sure if nesting them was a) possible b) good code or c) something that would bite me in the rear down the road.

Once I figured out what I was dealing with: “nested using blocks” I quickly found this blog post by Scott Hanselman, who specifically says in the comments of this post that he is thumbs up with “nested using blocks (but ONLY if theare are pure nestings without any other code following the inner block.”

So, considering the source, I’m confident that I’m doing good by doing well (or however that goes) with nested using blocks (with out extra code after the inner block). 🙂

Using fs as New FilesStream(myfilepath,FileMode.Open)
  Using sr as new streamReader(fs)
     Try

       … still need exception handling around the other code

     catch ….
    Finally
    End Try
  End Using
End Using

Don’t Forget: www.acehaid.org

Underscore-named variables and CLS Compliance in VB

dotNET

When I moved to .NET from VB6, I loved the ability to name variables beginning with an underscore. Now that I am porting some .NET 1.1 code to .NET 2.0, I am seeing that this in non-CLS compliant.

However, because the handful of variables that use the underscore are in a class that has many subclasses and some of these variables are used in the subclasses (shared, protected) AND because this class is not something that anyone else will ever use outside of my application, I have made an executive decision NOT to fix the variables but to set the CLSCompliant attribute from the Assembly information to False.



Don’t Forget: www.acehaid.org