April 2005 - Posts
Looks like Paint.Net 2.1 has been released.
I have been playing with the Whidbey Beta 2 for the last week and I have come across several bugs. Here are they ones I have submitted so far although I have more to put through.
Collapsed region box doesn't render tab characters correctly.
Bolded font bug in tooltips.
Incorrect tab autocomplete at the end of If and Select statements.
I have had a day to recover (read 'Get some sleep') from the first CodeCampOz. I had a great time and was able to meet some great people. I can now put some faces to the names. I met Mitch Denny and Greg Low, Darren Neimke (who finally put two and two together to realise that Rory who is a developer from Canberra who works with Geoff happens to be the same Rory who is a developer from Canberra and went to CodeCampOz with Geoff that he met the day before - don't worry Darren there are a lot of us/me), Andrew Coates, Bill McCarthy, Joel Pobar, Bill Chesnut, Nick Randolph and Charles Sterling to name a few.
Rather than give a session by session outline of what happened on CodeCamp and who said what, I will just mention a couple of things that I didn't already know and that are more than just a little cool.
Greg Low outlined some of the new features in SQL 2005 such as the ability to use CLR assemblies in queries. I can see a lot of use for these for manipulating data when inserting or selecting data, but I have to say that I was hoping to be able to do a little more with this new ability to make DBA's plead and tremble. I wanted to see a bit more ability for CLR objects to be able to map easier to columns in a table (OO style), but it still seems to be down to TSQL at the end of the day.
Adam Cogan talked about new ASP.Net data binding and navigation controls. Some of the new environment features that are great are collapsible tag contents in HTML view, much better intellisense support and accessibility compliance checking of the HTML output (government department developers will love this). There is now support for synchronising files between the local machine and remote servers which is a great improvement over simply uploading files. There is much better data binding support, such as the ability for data binding to append to the existing contents of a control rather than wipe it out. Caching support will also be a very interesting thing to check out as it comes with SQL Server support for identifying changes to the data as the event to reset the cache.
Andrew Coates ran a session on ClickOnce which is very useful, although perhaps a little optimistic on the naming. I can see a lot of benefit for places where I work for ClickOnce internet deployment to be used for applications. I am not sold on the implementation mainly from a UI point of view, but he mentioned that it is fully programmable so that shouldn't be a problem. I have thought about internet deployment of applications and updates for a few years and have seen some very good implementations, but also some very poor ones. ClickOnce has a lot of advantages, mainly being that there is separation of developers from the deployment process which should be a network administration responsibility. It is also something that is very quick and easy to deal with.
Darren Neimke talked about ASP.Net Web Part controls. These will be very cool to use, especially for portal type web sites as they will allow the users to customise how they want to see the site. Unfortunately I don't think that any of my sites can benefit from this. He did say a couple of words that I couldn't be sure were intentional. Regardless, we have some new words for the dictionary. Automagic/Automagical and Motzilla (cheesy Mozilla???).
Joel Pobar ran the next session on CLR internals. I didn't get anything specific out of this session, but it was very interesting. I had a chat to him later in the afternoon which was great. He had previously helped me out in the AusDotNet users group. He was a very friendly and happy to help out developers in need.
Bill Chesnut talked about BizTalk which I really enjoyed. It is yet another technology that I see could (should) be used in my current workplace to completely revolutionise business communication and the business process. I found it quite fascinating how BizTalk works and fits together to support the flow of data in, through and out of a business. With a great amount of hindsight, I can see that this is something that my previous employer should have used (instead of me having to write warehouse interfaces). I would love to get some exposure to this, especially because I would love to work for Avanade (they seem to do a lot of BizTalk). I was able to talk to Bill after the session to shoot some questions at him about how BizTalk would fit into my current work environment - Thanks Bill, very helpful.
Dominic Cooney talked about performance in managed applications. The most important performance tip I got from Dominic is that if you don't declare enums with a specific type, they default to Integer. This is a waste of space if you are only using numbers between 0 and 255. This is because an Integer use 4 bytes and a Byte (being values between 0 and 255) only uses one byte. As most enum declarations (except lengthy Bitwise ones) only use values under 255, they should be declared as Byte to save memory.
Nick Randolph and Bill McCarthy gave a very length session on VB.Net. Lots of great stuff here although I was already familiar with some of it. The first feature that hit me most were mixed scope declarations of properties. This means, for example, you can declare the property Get method as Public and the Set as Protected. The next main feature that I loved was the code snippet abilities. I always want code formatted the way I want it, and code snippets will be perfect for doing things like creating property skeleton code just they way I want it. Better and easier support for creating project and class templates are really cool. Creating default class definitions with dynamic comments will be so easy with this. Oh, and can anyone say Refactoring or Edit and Continue.
On Sunday, I had lunch with Nick and Bill and we had a great chat about VB, its future and current Whidbey implementation. We also came up with some great ideas about the VB/C# debate. As the two languages are getting closer and closer together, they were commenting that it really doesn't matter if you develop in one or the other as the difference is basically just syntax. That being the case, I think it is a shame that a lot of companies are asking for C# instead of VB developers.
This conversation did make me think about some solutions to this situation. Given that C# and VB compile down to the same IL anyway, how cool would it be if VB and C# could be used interchangeably. Take a webform for example. You can switch between the designer view and the HTML/XML view. This is where I think VB and C# should go. For any piece of code displayed, there should be a switch for whether it is displayed in VB or C#. This means that within the one assembly, you could have one developer create a version in VB, and a C# developer could come along and make changes, in C#. These should even be settings in the users IDE setup as to whether code should be presented and editable in VB or C#. I think this will be my request for the next version of Visual Studio.
Greg Low gave a session about ADO.Net. This was really helpful to see some of the new features like multiple recordsets, XML data types etc etc. I had a good chat to Greg at the end of the camp about support for OPENXML and FOR XML EXPLICIT. As with all new versions, there is so much to read and learn.
I said that I didn't want to give a session by session account of the weekend, but it kind of happened anyway. Thanks to all the people who ran the weekend, spoke in the sessions and for all the people who went along.
We have just arrived for day 2 of CodeCampOz. I meet several people yesterday (I'll talk about that later) and got to have a look at some great new stuff coming out of Microsoft.
It's at the start of the first session, it's dark, I'm wearing sunglasses and just had a caramel flat white standard to go. Ready to rock!
Over the last week, I have been able to have a bit of a play with the new Beta of Visual Studio and it has a lot of great stuff in it.
One of the initial things I came across was a single instance settings for WinForms. If the single instance setting is set, when a new instance of the application starts and there is already an existing instance running, the command line parameters of the new instance are passed to the existing instance, and the new instance is shut down. In the previous versions of VB, I had to include a decent amount of code to get this working (see VBAccelerator for a good example).
This is another example of how Microsoft are trying to do more work for us (obviously so that we don't have to). All of these types of features really help to speed up development times. As far as the single instance feature goes though, I do have one problem. It is a design-time setting. Why can't it be a runtime setting as well? This means that the app can only be single instance or multi-instance. To get runtime switching of this feature, you have to go back to coding it yourself.
The newer versions of Visual Studio have come a long way as far as what you can do with the inbuilt functionality at runtime, where those features were previously design-time only. The question I always ask myself when I see new design-time settings is whether there is a valid case for that setting to be changed at run-time. If it is a feature that could be more useful if it was settable at run-time, why make them design-time only in the first place? The two obvious answers to that question are that either a) they didn't have time to build the features as run-time configurable or b) the designers disagree with my opinions (I don't BTW really want that question answered :P).
For the last couple of weeks, I have been developing a cool ASP.Net app that allows customer administrators to make requests for users to be added to Active Directory and given access to their instances of online products. This has all been working great, until yesterday.
This solution, which is stored in ClearCase, has a lot of projects in it and I wanted to get some good naming of namespaces. I also changed the names of the projects to represent their namespaces. This worked well for all of last week with only problem being a few instances of locked files in VSWebCache, but another rebuild tended to get rid of those.
Yesterday morning, I installed Whidbey Beta 2 to have a bit of a play. At the same time, a colleague made some changes to the ClearCase configuration for the solution. Take Thy Gun.......
All hell starts to break loose. Each time I start the web project, the objects in the ASP.Net assembly can't be found. Is it ClearCase or Beta 2 at fault????
After pulling my hair out for the 1093850923842314th time ( And Shoot Thy Foot........Repeatedly), I hadn't gotten anywhere. I built the solution several times on multiple machines (with and without Beta 2), using several ClearCase views and differing combinations of everything under the sun. There was no consistency as to whether the web project would run or not.
I finally discovered that as soon as I referenced a project (which was under ClearCase) to my blank test ASP.Net project (which wasn't under ClearCase), I found that it didn't find the web projects objects and the VSWebCache locking compile errors started again. I removed the ClearCase related projects from the web project and the web project would then work again. This would indicate that ClearCase is the problem. ......Repeatedly.
In the end, it wasn't ClearCase and it wasn't Beta 2 being installed. It turns out that the ASP.Net project got an upset stomach when the namespace was changed from NiceName to PrefixName.NiceName. I don't know if it didn't like multiple names in the namespace or if it threw wobblies because there was a . character in the namespace.
Needless to say, I have had a very productive two days. The gun is back in the holster, ready for another day.
It has been a busy couple of weeks recently that have prevented me from giving any decent attention to the skinning engine. I have however been able to give a bit of time to it now.
My most recent development on the skinning engine has highlighted that my current implementation isn't flexible enough to support the rendering functionality that I am after. I will have to make some changes to my design before continuing. I have mainly been focusing on developing the rendering of windows and buttons in the skinning engine. Hopefully there will be more progress over the next couple of weeks.
For the last couple of days at work, I have been developing a new ASP.Net site. Across all the pages in the site, there are some common methods and properties that need to be used. In the case of this new application, I needed to check if the authenticated user has permissions in Active Directory to see the details of the user they are requesting.
The easiest way to achieve this common functionality is to create a base class that inherits from System.Web.UI.Page. Each WebForm code behind page can then inherit from the custom class instead of the default System.Web.UI.Page class. I hit some interesting problems with developing this solution in the VS IDE.
The first problem is that the design-time view of the pages usually didn't render because it couldn't identify the custom class. This was caused because I initially had the custom class in the ASP.Net project. This is an issue because the design-time render needs a compiled class to render controls and pages as it doesn't interpret uncompiled code. As the class was in the web project , the assembly may not yet be compiled, or if compiled, it usually can't be resolved.
To fix this problem, I separated the custom class out into a class library which was referenced by the web project. This meant that when the designer attempted to render the design-time display, it had a compiled assembly that it could resolve and use.
The second problem was that the IDE was continuously locking files in the .Net cache. This caused compiling problems with the solution. I can only guess that this second problem was caused by the custom class being in the web project as they haven't happened since I separated the class out into another project.
CodeCampOz - I'll be there. Will you?
The main purpose of creating controls is so they can be reused in other projects. The beauty of Web Custom Controls as opposed to Web User Controls is that they are compiled into an assembly which can easily be copied between ASP.Net projects. When I...
I have been having a couple of issues with Bloglines recently. It is the best overall feed reader I have used, but there are a few things that I don't like about it. It doesn't always do the best job of rendering HTML of feed items (especially code examples) and often renders the content off the width of the screen (although this may be forced by the HTML). My main problem with it is that it is constantly displaying new entries that are not new.
My guess was that the Bloglines storage of entries gets cleared after a certain amount of time, but if a feed isn't updated, then the same items are added back into Bloglines and displayed as being new. I have killed that theory because today, one of my own entries came up as new, but it was created on the 7th of Feb and none of the surrounding entries were identified as being new. Fairly weird behaviour here. It is a little annoying having previously read items come up again.
Being a programmer, I am often trying out new software and looking at new ideas. The problem I have is that I too often want the app to do something a little different. This usually means that I end up writing my own implementation.
I guess there is going to be an RSS reader being worked on in the future. Only then will I get it to do exactly what I want.
We had a Tae Kwon Do graduation this morning. My wife and I both completed a double grading to go to a Green belt. We are now at the start of the intermediate ranks.
For the new .Net version of my Switch program, I need to take screen captures to display part of the screen in the application. I have hit some interesting snags though. They are not deal breakers, but annoying none the less.
The typical way to capture the screen is to get the handle to the desktop window by calling GetDesktopWindow. With that hWnd, we get its Device Context by calling GetDC, from which we can copy the image to our own Graphics and Bitmap objects using the BitBlt API.
The first issue surrounds windows that have been created (or since updated) with the WS_EX_LAYERED style. This flag allows for alpha-blending and/or a transparent colour to be defined for a window.
First scenario:
Getting a screen capture of the desktop doesn't render layered windows at all.
Second scenario:
If an hWnd is obtained for a layered window instead of the desktop window, the screen capture code does render the form, but renders it as if it wasn't layered (no alpha blending and no transparent colour). This is logical because the window still renders the entire image on its own DC whereas the layered support translates that for screen rendering.
Third scenario:
Here is where it gets interesting. Ctrl+Print Screen does capture layered windows along with its transparent colour correctly used, but ignores the alpha-blending.
For my purposes, the third scenario is the perfect way to capture the screen. My question is how does Ctrl+Print Screen do it? I can't find anything helpful on the Internet or in MSDN. I have requested the guru, Raymond Chen, to post an article about this which will hopefully shed some light on the issue.
As a side note about layered windows, if a .Net WinForm isn't set with either a TransparencyKey or Opacity value other than the default values, the window is created without the WS_EX_LAYERED style. As soon as one of these values are changed, Reflector shows us that the form style is updated to include the style bit.
If ((Me.OpacityAsByte < 255) AndAlso OSFeature.Feature.IsPresent(OSFeature.LayeredWindows)) Then
Me.AllowTransparency = True
Me.formState.Item(Form.FormStateLayered) = 1
End If
When the property values are set back to System.Drawing.Color.Empty and 1.0 respectively, the style bit isn't removed. This is understandable. After all, why would you want to remove the style bit. It would however be helpful to me though as the forms won't rendering in the screen captures when they could if the redundant style was removed.
Unfortunately the TransparencyKey and Opacity properties are not overridable. For my skinning engine at least, I got around this by running this line of code after assigning new values to either of those properties.:
Me.AllowTransparency = (Me.Opacity <> 1 OrElse Me.TransparencyKey.Equals(System.Drawing.Color.Empty) = False)
Anyway, the second issue I have with screen captures is that I would like to be able to render the current cursor as well. This also seems to be more than a little difficult. All the examples I have seen attempt to load the cursor and render it on their screen capture Bitmap after the fact. I don't think this is the best solution. There must be another way.
If anyone has some ideas, please let me know.
Just got this emailed to me. Definitely something to think about.
1. Japanese eat very little fat and suffer fewer heart attacks than the Aussies, British or Americans.
2. Mexicans eat a lot of fat and suffer fewer heart attacks than the Aussies, British or Americans.
3. Japanese drink very little red wine and suffer fewer heart attacks than the Aussies, British or Americans.
4. Italians drink excessive amounts of red wine and suffer fewer heart attacks than the Aussies, British or Americans.
5. Germans drink a lot of beer and eat lots of sausages and fats and suffer fewer heart attacks than the Aussies, British or Americans.
CONCLUSION:
Eat and drink what you like. Speaking English is apparently what kills you.
When I create Web Custom Controls, I usually have some JavaScript that needs to be rendered with them. There are several methods of building and rendering scripts for controls and some of these methods are definitely better than others. I have seen scripts...