This is my fourth positive post in a row - I must be sick.
You have got to check out the System.IO.File object.
It features AppendAllText(string path, string contents) that creates a file (if it does not already exist) and adds the text to the end. This was just annoying code that had to be written once every project and now we are free of those shackles.
Also check out the Open*() functions, Write*() and Read*() functions.
Cool.
I will find something to have a whinge about soon I am sure...
Friday, January 20, 2006
This camper is getting even happier...
So I am fumbling around with VS2005 treating it like VS2003 and just stumbling across the new features (as opposed to reading the books or the help). Every now and then you find something that is really simple but is just excellent.
The output window now shows the statement the IDE has used to compile the project. This was not in VS2003 and to create some automated build/deployment script required some mucking around working out all of the damn command line arguments.
Not anymore - a copy and paste later and your done.
The command line to compile this relatively small WinForms app was 1671 characters long (an entire command prompt screen's worth). I am really happy that I did not have to type that in.
:)
The output window now shows the statement the IDE has used to compile the project. This was not in VS2003 and to create some automated build/deployment script required some mucking around working out all of the damn command line arguments.
Not anymore - a copy and paste later and your done.
The command line to compile this relatively small WinForms app was 1671 characters long (an entire command prompt screen's worth). I am really happy that I did not have to type that in.
:)
Thursday, January 19, 2006
Generics, Transactions, Nullable Types... all crap when compared to...
I have just written my first 'serious' WinForms app in .Net2. Before going home for the day it was time to create the Deployment project. I hate doing Deployment projects. You have to worry about Framework boot strappers and the like to make it a seamless experience.....
Well not anymore!!!!
The new Setup Wizard in Setup and Deployment basically asked what type of deployment I wanted (WebForms, WinForms, etc) and whether I wanted any other files included. I created a shortcut to the project's main output (I think this is a lot easier in this version) and built it.
This was pretty similar to VS2003 up to this point.
In looking in the output directory there were two files. setup.exe and an MSI file. In a vanilla WinXP SP2 VPC I loaded the MSI file. It said politely that the Framework was required and would I like to download it from Microsoft's web site. This was pretty good but I was then faced with the web page asking what version of the framework that I wanted to download and whether it was the distributable or the SDK, etc. This is not a very good user experience.
I then thought to try the setup.exe. I am please I did! It comes up with a licensing agreement screen followed by a screen describing everything that needs to be downloaded and whether I would like it to proceed - you bet! It then downloaded the Framework V2, installed my application and it all worked and it didn't even require a reboot. I guess it would also download MDAC (maybe DirectX) if required but I have not looked into that yet.
This is now a really nice experience for both the developer and the user.
I am one happy camper. Well does MS!
Well not anymore!!!!
The new Setup Wizard in Setup and Deployment basically asked what type of deployment I wanted (WebForms, WinForms, etc) and whether I wanted any other files included. I created a shortcut to the project's main output (I think this is a lot easier in this version) and built it.
This was pretty similar to VS2003 up to this point.
In looking in the output directory there were two files. setup.exe and an MSI file. In a vanilla WinXP SP2 VPC I loaded the MSI file. It said politely that the Framework was required and would I like to download it from Microsoft's web site. This was pretty good but I was then faced with the web page asking what version of the framework that I wanted to download and whether it was the distributable or the SDK, etc. This is not a very good user experience.
I then thought to try the setup.exe. I am please I did! It comes up with a licensing agreement screen followed by a screen describing everything that needs to be downloaded and whether I would like it to proceed - you bet! It then downloaded the Framework V2, installed my application and it all worked and it didn't even require a reboot. I guess it would also download MDAC (maybe DirectX) if required but I have not looked into that yet.
This is now a really nice experience for both the developer and the user.
I am one happy camper. Well does MS!
Saturday, January 14, 2006
The debugger is AWESOME
I have had a play with the VS2005 mainly with WinForms and now some debugging.
The WinForms forms editor just rocks. I love the way the controls get sticky around the place they should be placed. No more emails from pesky users saying that a text box is a couple of pixels misaligned - I cannot delete those emails fast enough.
But the debugger is just the best. You can hover the mouse over a variable, drill into its data and even edit its values all from a little popup window. OK - sometimes you need the hand-eye coordination of a brain surgeon to move the mouse over the left hand side of the pop up window to expand its details but I enjoy the challenge. There will be a short cut key I am sure but it have not chanced across it yet.
I really love the text visualiser where you can see the contents of the variable displayed as text, html or XML. I would have loved to have seen a byte[] to string visualiser but alas. In this particular project I am moving around byte[] but they normally contain just ascii so such a visualiser would have been the cream on the cake.
I am impressed with this.
The WinForms forms editor just rocks. I love the way the controls get sticky around the place they should be placed. No more emails from pesky users saying that a text box is a couple of pixels misaligned - I cannot delete those emails fast enough.
But the debugger is just the best. You can hover the mouse over a variable, drill into its data and even edit its values all from a little popup window. OK - sometimes you need the hand-eye coordination of a brain surgeon to move the mouse over the left hand side of the pop up window to expand its details but I enjoy the challenge. There will be a short cut key I am sure but it have not chanced across it yet.
I really love the text visualiser where you can see the contents of the variable displayed as text, html or XML. I would have loved to have seen a byte[] to string visualiser but alas. In this particular project I am moving around byte[] but they normally contain just ascii so such a visualiser would have been the cream on the cake.
I am impressed with this.
Sunday, January 08, 2006
Thread Priority
I am working on a multithreaded WinForms component in some spare cycles.
There are a heap of worker threads and to keep the UI responsive I set the priority of the worker threads to below normal. Its a technique that works really well.
The component raises events that the UI responds to. In testing the event handlers I checked the thread priority to make sure that it had bubbled up from the component in below normal priority. I discovered that it was in normal priority. Something was very strange.
It turns out in .Net when you start a thread it starts in normal priority, not the priority of the thread that launched it. To get around this you need a some class member that records what the thread priority should be and when a new thread starts it needs to check this member and set its own priority accordingly.
I can't help but think that this was a poor design decision.
Apparently Java's thread do inherit their priority from their parent.
There are a heap of worker threads and to keep the UI responsive I set the priority of the worker threads to below normal. Its a technique that works really well.
The component raises events that the UI responds to. In testing the event handlers I checked the thread priority to make sure that it had bubbled up from the component in below normal priority. I discovered that it was in normal priority. Something was very strange.
It turns out in .Net when you start a thread it starts in normal priority, not the priority of the thread that launched it. To get around this you need a some class member that records what the thread priority should be and when a new thread starts it needs to check this member and set its own priority accordingly.
I can't help but think that this was a poor design decision.
Apparently Java's thread do inherit their priority from their parent.
Friday, January 06, 2006
Scroll bars - rant and some suggestions for Help
I was working on a Pocket PC application this morning. I had a custom control consisting of a panel with a panel within it and a scroll bar on the right. It effectively created a scrollable canvas in which other controls could be placed.
I had all of the trouble in the world with getting the very bottom of the canvas to display. The scroll bar did not seem to be working correctly. Since there was a little maths to work out the max value, large increment and the panel's top property I figured that the problem lay there.
It was only after a bit of debugging that I found that the scroll bar was incapable of reaching its maximum value of 100. It would stop at 91 irrespective of whether it would be moved through a small change, large change, or manual drag.
A search of Google later revealed that the maximum value of a scroll bar is at most MaximumValue - (LargeChange + 1) as quoted from http://msdn.microsoft.com/smartclient/understanding/netcf/FAQ/default.aspx#5.40
This is actually incorrect. It is Maximum - LargeChange + 1 (the brackets stuff it up)
I checked it on WinForms and the same. There is even a passing note about it in the help: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformsscrollbarclassmaximumtopic.asp
There is not much chatter on the web about this problem so I figure it should be fleshed out a bit.
I checked in VB6 and this problem does not occur.
What a stuff up!
Two things:
1. This is going to be with us for the entire life of .Net.
Today I wrote code recognises this problem and takes it into account when calculating the 'real' maximum. If it were ever to be fixed in the framework then my program will no longer function correctly. Microsoft will never be able to fix it since if they do then software will break.
(I guess the could release a new scrollbar called ScrollBarEx while keeping the old one around for compatibility.)
2. Finding information about this was a little difficult. There is a note in the Maximum property field of the ScrollBar help. No mention the Value property and no mention in the ScrollBar class. In fact it only says:
This is a bit misleading especially if you set the LargeChange to be the same as Maximum. The maximum value ever reached will be 1.
While I am at it, they were smart enough to recognise that the LargeChange could not exceed Maximum when in design mode and the LargeChange gets reset back to Maximum if it is exceeded - well you would think so. They stuffed this up too. The LargeChange value is reset back to Maximum + 1.
I have just finished reading the Framework Design Guidelines. I will post about this later. The refreshing aspect of this book is that Microsoft insiders add their comments and admit to mistakes that were made. This was great. When programming against those areas of the framework that contain these problems, rather then being frustrated I find myself being accepting of the issues in the knowledge that the designers themselves know that they could have done a better job - reading and writing a simple text file for example.
I think that this should be extended to the Help. Along with sections of Thread Safety, Remarks, Examples, Requirements and See Also there should be another section called "Narration" or "Background information" or "Editorial". This section would allow frank comments to be added by the Microsoft Team to express why things were done the way they were done, the history, the mistakes that were made, what influenced their design decisions, how to best use the class or property, etc.
This would be a very disarming and I think would provide for a much better help system.
In the example of the scrollbar I would except that they would say:
:) That was a bit harsh.
I had all of the trouble in the world with getting the very bottom of the canvas to display. The scroll bar did not seem to be working correctly. Since there was a little maths to work out the max value, large increment and the panel's top property I figured that the problem lay there.
It was only after a bit of debugging that I found that the scroll bar was incapable of reaching its maximum value of 100. It would stop at 91 irrespective of whether it would be moved through a small change, large change, or manual drag.
A search of Google later revealed that the maximum value of a scroll bar is at most MaximumValue - (LargeChange + 1) as quoted from http://msdn.microsoft.com/smartclient/understanding/netcf/FAQ/default.aspx#5.40
This is actually incorrect. It is Maximum - LargeChange + 1 (the brackets stuff it up)
I checked it on WinForms and the same. There is even a passing note about it in the help: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformsscrollbarclassmaximumtopic.asp
There is not much chatter on the web about this problem so I figure it should be fleshed out a bit.
I checked in VB6 and this problem does not occur.
What a stuff up!
Two things:
1. This is going to be with us for the entire life of .Net.
Today I wrote code recognises this problem and takes it into account when calculating the 'real' maximum. If it were ever to be fixed in the framework then my program will no longer function correctly. Microsoft will never be able to fix it since if they do then software will break.
(I guess the could release a new scrollbar called ScrollBarEx while keeping the old one around for compatibility.)
2. Finding information about this was a little difficult. There is a note in the Maximum property field of the ScrollBar help. No mention the Value property and no mention in the ScrollBar class. In fact it only says:
To adjust the value range of the scroll bar control, set the Minimum and Maximum properties.
This is a bit misleading especially if you set the LargeChange to be the same as Maximum. The maximum value ever reached will be 1.
While I am at it, they were smart enough to recognise that the LargeChange could not exceed Maximum when in design mode and the LargeChange gets reset back to Maximum if it is exceeded - well you would think so. They stuffed this up too. The LargeChange value is reset back to Maximum + 1.
I have just finished reading the Framework Design Guidelines. I will post about this later. The refreshing aspect of this book is that Microsoft insiders add their comments and admit to mistakes that were made. This was great. When programming against those areas of the framework that contain these problems, rather then being frustrated I find myself being accepting of the issues in the knowledge that the designers themselves know that they could have done a better job - reading and writing a simple text file for example.
I think that this should be extended to the Help. Along with sections of Thread Safety, Remarks, Examples, Requirements and See Also there should be another section called "Narration" or "Background information" or "Editorial". This section would allow frank comments to be added by the Microsoft Team to express why things were done the way they were done, the history, the mistakes that were made, what influenced their design decisions, how to best use the class or property, etc.
This would be a very disarming and I think would provide for a much better help system.
In the example of the scrollbar I would except that they would say:
Editorial
We had the work experience student in that week so we gave them the scrollbar to write - how could they possibly stuff it up. We apologise.
:) That was a bit harsh.
Wednesday, January 04, 2006
A trap for beginners
The icons in Visual Studio have not changed since VB3 (maybe even earlier). If I see that space shuttle, oscilloscope or bicycle one more time I am going to scream.
Fortunately the icons have been revamped in VS2005 - at least in some beta that I saw. Now that we have the final release I thought i would add some great icons to a test application that I was playing with.
In selecting a icon for the application I navigated to C:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary using Visual Studio - but nothing! Were they cut from the final product? I did the full install. Are we going to be forced to use the space shuttle forever?!??!?
Do not despair! They are not present in the IDEs file selection window because they are all zipped up in a file called VS2005ImageLibrary.zip and the file name filter is set to .ICO so it does not appear. A quick unzip later and you will have all of the icons that you will ever need - for about week anyway.
Fortunately the icons have been revamped in VS2005 - at least in some beta that I saw. Now that we have the final release I thought i would add some great icons to a test application that I was playing with.
In selecting a icon for the application I navigated to C:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary using Visual Studio - but nothing! Were they cut from the final product? I did the full install. Are we going to be forced to use the space shuttle forever?!??!?
Do not despair! They are not present in the IDEs file selection window because they are all zipped up in a file called VS2005ImageLibrary.zip and the file name filter is set to .ICO so it does not appear. A quick unzip later and you will have all of the icons that you will ever need - for about week anyway.
Tuesday, January 03, 2006
GZipStream and Deflate compression
I have had a low priority project floating around for about 6 months that requires some analysis of various files and how well they have been compressed. Since VS2003 did not have any compression support and the fact that I did not want to evaluate, choose, buy and learn a third party compression library (this project is just not worth it) I chose to wait until VS2005 since it was to have some compression support.
As an aside, this was my very first VS2005 project. At first glance it really does look totally awesome. However I will reserve my final judgment until I get into my first big ASP2.NET application.
The Help is really good on the compression topic. I was not looking forward to all that mucking around with streams but the examples did exactly what I wanted and a quick copy and paste later my program was basically finished.
The first file that the program checked was a PDF. PDFs are inherently compressed so I wasn't expecting it to reduce in size my much. But I did not expect that it would INCREASE in size by 50%! A small check of the code later and it was no bug.
The compression in VS2005 has two flavors; one based on GZip and the other on the Deflate algorithm. The help says that GZip actually uses the same algorithm as Deflate but it can be extended to use other formats.
I did a bit of analysis to see how much the files would compress by. (The results of PDF file seen in this table are of a different PDF file that initially alerted me to these issues hence the discrepancy)
From these results that it is clear that it is not wise to use the .Net compression libraries on data that is already highly compressed. It will make the data 50% bigger then it was originally. If the data is somewhat compressed (PDF and Word) then there is little benefit in using these libraries.
However if the data is not at all compressed then the compression works well. For example if you are moving around XML data (ie SOAP, etc) then it may be a great idea to compress the stream. (caveat emptor - CPU load will go up and you will lose compatibility with computers not supporting the decompression algorithm. This is kind of against the spirit of SOAP)
Another point is that Help's claim that the GZip's algorithm is the same as Deflates appears to be totally true. The files come out to be slightly different sizes but I can only assume this has something to do with header sizes.
The compression libraries work on streams rather than 'block mode'. The libraries compress the data as it arrives from the stream rather then having an opportunity to examine the entire data file from beginning to end and then compressing as is done in programs like WinZip. Stream based compression apparently can never be as good as block compression.
So back to my problem. In determining whether a file is really well compressed I have resorted to checking whether the .Net GZip algorithm increased the size by more then 50%! If it does then it is really when compressed otherwise there maybe an opportunity for further compression.
As an aside, this was my very first VS2005 project. At first glance it really does look totally awesome. However I will reserve my final judgment until I get into my first big ASP2.NET application.
The Help is really good on the compression topic. I was not looking forward to all that mucking around with streams but the examples did exactly what I wanted and a quick copy and paste later my program was basically finished.
The first file that the program checked was a PDF. PDFs are inherently compressed so I wasn't expecting it to reduce in size my much. But I did not expect that it would INCREASE in size by 50%! A small check of the code later and it was no bug.
The compression in VS2005 has two flavors; one based on GZip and the other on the Deflate algorithm. The help says that GZip actually uses the same algorithm as Deflate but it can be extended to use other formats.
I did a bit of analysis to see how much the files would compress by. (The results of PDF file seen in this table are of a different PDF file that initially alerted me to these issues hence the discrepancy)
| File | GZip | Deflate |
| 1000000 spaces | 0.86% | 0.86% |
| A Word document | 88.60% | 88.57% |
| A Word document zipped | 152.97% | 152.90% |
| A PDF | 92.76% | 92.75% |
| A PDF zipped | 153.35% | 153.34% |
| An XML file | 3.24% | 3.24% |
| An XML file zipped | 145.46% | 145.46% |
From these results that it is clear that it is not wise to use the .Net compression libraries on data that is already highly compressed. It will make the data 50% bigger then it was originally. If the data is somewhat compressed (PDF and Word) then there is little benefit in using these libraries.
However if the data is not at all compressed then the compression works well. For example if you are moving around XML data (ie SOAP, etc) then it may be a great idea to compress the stream. (caveat emptor - CPU load will go up and you will lose compatibility with computers not supporting the decompression algorithm. This is kind of against the spirit of SOAP)
Another point is that Help's claim that the GZip's algorithm is the same as Deflates appears to be totally true. The files come out to be slightly different sizes but I can only assume this has something to do with header sizes.
The compression libraries work on streams rather than 'block mode'. The libraries compress the data as it arrives from the stream rather then having an opportunity to examine the entire data file from beginning to end and then compressing as is done in programs like WinZip. Stream based compression apparently can never be as good as block compression.
So back to my problem. In determining whether a file is really well compressed I have resorted to checking whether the .Net GZip algorithm increased the size by more then 50%! If it does then it is really when compressed otherwise there maybe an opportunity for further compression.
New years resolution
I have benefited hugely from the .Net community of bloggers. To such an extent that feel that it is time to give something back. This blog will explore some of the highlights, intricacies and frustrations of a professional developer who spends too much of his life in front of Visual Studio.
Subscribe to:
Posts (Atom)