Dogpike

MS Will Release VS Service Packs!

2005-11-08T12:05:00.000+00:00

I've blogged about it before, but back in the old days (for Visual Studio versions prior to 7, aka .NET), MS used to release regular service packs for bugs in the development environments. This was back when most languages had their own IDEs (by version 6 they were pretty much integrated, apart from VB). As I've said, regretfully, MS abandoned this when Studio 7 (".NET") came out. Although they've released a few service packs for the .NET Framework, they didn't bother patching the IDE. Oh, there were loads and loads of little "hot fixes", but you had to contact support for those, and there was no real guarantee of quality.

Finally, finally, finally, MS have announced they'll be releasing service packs for Visual Studio 2003, and 2005.

Unfortunately, these won't be available until the middle of next year. I don't understand why the service pack for VS 2003 isn't available until June 2006. I mean, how long has this product been out already? As for VS 2005, there have been worrying rumours of nasty bugs and poor performance. I've got plenty of experience of using the beta versions of the original Visual Studio .NET, as my company at the time made the exciting and frankly foolhardy decision to use beta 1 for a major product development. Since those painful days, I've steered well clear of beta releases of MS dev tools (unless they're quarantined in a VM and I don't have to do any real work with them other than "playing"). So, I think I'll steer well clear of VS2005 RTM until the release of sp 1 sometime in the 1st half of next year.

Ignoring the Express Editions, Visual Studio is an expensive beast. Expensive, and buggy, in my opinion. I've used it every day since the release of beta1 in December 2000 - that's just shy of five years. And I'm still waiting for the cool, efficient and stable dev tool they promised us back in the summer of 2000.

MS Expression

2005-09-16T19:11:00.000+01:00

I've talked about XAML / Avalon in previous posts, and how this will be used to generate revolutionary new UIs. MS have come up with previews of 3 new tools to enable this. The product range is known collectively as "Expression", and comprises:

Quartz Web Designer;
Acrylic Graphic Designer;
Sparkle Interactive Designer;

The next version of Visual Studio, codename "Orcas" will replace the current Web Forms designer with Quartz. I'm assuming Sparkle will form the equivalent designer for Windows Forms (some folks are also comparing Sparkle with Flash). Acrylic is a graphic design tool, which you can use in conjunction with both Quartz and Sparkle. If you take the time to read up on these tools, and see what Avalon is capable of, you'll see that there's an exciting time ahead for UI development.

More Evidence for an Apple Tablet

2005-08-24T20:22:00.000+01:00

I mentioned in a previous post that it looked like Apple might be considering putting out a Mac with the Tablet form factor. Engadget are reporting that Apple are now looking for a new handwriting recognition engineer, so maybe this idea isn't as far fetched as some were claiming.

I've said before that I think the Tablet is a great idea, and that I really want one. At the moment, they're in a bit of a niche position. Most manufacturers are producing them, with the notable exception of Dell, and they're not really seen currently as anything more than a toy.

The competition from Apple might just be good for the form factor, and encourage the likes of Dell to take Tablet machines seriously.

The Future of MS Platform Apps Development

2005-08-18T22:36:00.000+01:00

I'm sure everyone knows by now that the next generation of apps for the Win platform will make use of Xaml (extensible application markup language), which is an Xml dialect used to define UIs - one set of markup will work just as well for thin and thick client apps (see my earlier posts on Xaml and Avalon pt. 1, & pt. 2, now known as Windows Presentation Foundation).

A lot of people recently have been comparing Xaml with Flash, and it's true - you will be able to have real whizzy graphical effects in your apps. Within a few years, the programs you use and develop today will be unrecognisable.

"So," everyone asks when I tell them this, "does that mean I need to become a graphic designer?"

MS have quietly released a preview version of a graphics tool called Acrylic, which apparently now exports to Xaml.

This tool will find its way into the next generation of dev tools from MS (apparently there's also another related tool on the way) - we're talking a year or two down the line once Vista is out - but you can begin to imagine what things will be like.

Some First Impressions on IE7

2005-07-28T22:09:00.000+01:00

Robert McLaws has installed IE7 beta1 and has some interesting first impressions; looks like he hates the way tabbed browsing is implemented, and the new UI reorganisation (where the menu is no longer at the top, it's in the middle... see my last post).

Personally, I'm toying with the idea of installing Vista on a VM on a spare machine, but I may wait for beta 2.

Want Info on IE7 Beta1?

2005-07-27T23:26:00.000+01:00

Download the technical overview doc here.

Key features:

Anti-phishing (enhancements to the security status bar to alert users to issues with site certs, maintains a list of known phising sites and warns the user, etc);
1-click cleanup of browser history;
Tabbed browsing! (sigh). Number 1 requested feature. Personally, I think it's overrated. The IE team had to make a lot of changes to the IE codebase to add this; I'm sure I'll learn to love it;
Toolbar search. Integrated, extensible searching built into the toolbar;
Improved printing;
A "Cleaner, Sleeker UI" - they've monkied around with the toolbars; the Back /Forward buttons now sit to the left of the address bar; the stop and refresh buttons have been combined and now sit where the little green "Go" button used to be (i.e., to the right of the address bar); next comes the tabbed browsing tabstrip, finally, the menu (that used to be right at the top) & the toolbar with smaller buttons to maximise screen real estate. Frankly, it looks a little odd... and I've heard that not all the UI enhancements are in beta1... we must wait for beta2 (incidentally, this is also true of Win Vista itself, so I guess they're still working on Aero Glass & we have to wait a little longer to see it);
RSS Support - discovery & subscription, & more features slated for beta2;
Not much on developer features, but apparently there's better CSS & transparent png support;

Finally, a lowdown of how all those project codenames have changed:

"Longhorn" - Windows Vista (apparently MS want us to pronounce this "veesta", but sod that) - actually, I quite like the name, but don't confuse it with Vista Windows, or, er... Vista Windows;
"Avalon" - Windows Presentation Foundation (yawn);
"Indigo" - Windows Communication Foundation (yawn, yawn, yawn);
Direct3D 10 - Windows Graphics Foundation 2.0 (WGF2);
"ClickOnce" - they were going to give this a swanky new name... trouble is, they couldn't think of anything swankier than "ClickOnce", so that's what it will be called.

Windows Vista, aka "Longhorn"

2005-07-21T21:17:00.000+01:00

Apparently the product name of the next version of Windows (project "Longhorn") will be Windows Vista...

More Romany Words in Current English Usage

2005-07-19T17:38:00.000+01:00

Following on from my last post, and to highlight the fact that Gypsy culture has been integrated with English culture for the last couple of hundred years, here's some AngloRomani loan words (I already mentioned chav, pal and cosh); at least some of these words will be familiar to fans of Only Fools and Horses:

Kushti - lucky;
Scran - food (or to beg);
Shiv - a blade / knife;
Mush - means bloke, and incidentally:
Bloke - means man, from the Romany word loke (same word in Hindi);
Wonga - means money, but derived from Romany word wanga, meaning "coal";
Nark (as in informer) - originally from the Romany word naak, meaning "nose";
Posh - disputed, but believed to derive from posh karoon, meaning "half a crown", coins which Romanichals used as buttons to show off their wealth;

Interesting, eh?

Quite the opposite of the Daily Mail's decision to portray Romanichals as troublemakers and interlopers.

More can be found here.

Hell is Other People's Code

2005-07-14T18:00:00.000+01:00

There are two real phenomena out there in IT.

The first one is what I call "Hell is other people's code" (with apologies to Jean-Paul Sartre). This is where you inherit a code base that you must now maintain and extend. You declare to all who will listen that "it's rubbish". You'll swear and curse as you read through it. You'll make jokes about it in the pub with your friends.

Joel Spolsky describes this pretty well in Things you should never do, part 1.

The second is what I call "IT Proselytes". This is where people adopt every little new "trendy" methology or tech that crops up. OK, so we have "agile development", XP, then Scrum... all of a sudden someone else jumps onto the bandwagon and invents "Lean Software Development", which creates further spin-offs. Then you have the proselytes, who gush about these things in their blogs in a bid to be the first to declare that they're using XYZ technology with abc process, and how you should be using it too... I guess there's a certain amount of kudos in this. It's the IT equivalent of inventing a new diet. "I used iXP and shed 50 pounds!"

Mike Spille describes why this isn't such a good idea in Action Hippo Rangers! People who are the first onto a bandwagon tend to be the first to fall off.

Hooray for Atlas!

2005-06-29T09:16:00.000+01:00

Whe I first started using ASP.NET I was intrigued by the concept of server controls. I thought, wow, we can lose all that client-side script that is so tricky to write and debug. It quickly became clear the model was flawed. You really, really can't abandon client-side technologies when you're creating web pages. The user experience is just too disjointed and sluggish. Sure, MS intriduced Smart Navigation, to try to reduce some of the issues intriduced by postbacks, but it was always just a sticking plaster over a deeper problem. To write a decent site, you had to pretty much abandon server controls, viewstate, and so on, and pull out your DHTML and JavaScript reference.

I was always really annoyed that MS completely ignored client-side scripting - there's just no real tool support.

I've already commented on AJAX on this blog. I'm really pleased to see that MS are planning a new suite of tools & techs - codenamed Atlas - built on ASP.NET 2.0, to support client-side web development. You can read about it on Scott Guthrie's blog.

The Future of VB

2005-06-16T21:49:00.000+01:00

I recently mentioned the outcry of VB.old devs at the prospect of moving to VB.net now that the mainstream product support for VB.old has expired. My basic point was that VB.net is better than vb.old, and I was finding it hard to understand why anyone would want to cling to a dying language and toolset.

Then I got to thinking a little more deeply about the issue...

VB was always meant to be a RAD language / toolset. The idea was that you could have folks with rudimentary IT skills create simple programs and automate tasks. For this reason, VB became extremely popular - it was trivial to create GUIs, compare with C++; you could do so much more in a fraction of the time. Gradually more and more people adopted VB, including seasoned developers. As a result, developers demanded more and more from the toolset, the most common cry was for OO, which was kind of delivered in VB5 (arguments raged over whether VB was an object oriented language or not - but let's face it, it wasn't).

So, VB had to serve two masters - the experts who liked the ease of use but wanted a "proper" programming language, and the less sophisticated developers, who just wanted to get the job done. Two kinds of applications were developed as a result - enterprise level apps, that frequently hit the limitations of VB, and small-scale apps that were frequently hard to maintain and extend.

With VB.net 1.x, a lot of the RAD was lost; suddenly there was a yawning gulf between what VB.old developers knew, and where they had to go in order to upgrade their skills. The language now supported OO, and this in itself was a tricky learning curve for those VB devs unused to the discipline. The .net Framework is vast, and there's a lot to learn. VB.net became a grown-up language, and so pleased half of the VB devs (although a lot of these migrated to C#) but left the other half of the user base cold.

So where does VB go from here?

A major problem preventing migration of VB.old to .net are all those VB legacy apps; the conversion wizard in .net 1.x wasn't good enough for most devs, in that it only converted some of your code, leaving large parts untouched for devs to code themselves. When you're new to the framework, this is a daunting proposition; for this reason, the usual recommendation is to re-write your apps in .net, rather than migrate. Perhaps the wizard is improved in version 2?

It seems MS are making concerted efforts to return RAD to the language with version 2, what with "Edit & Continue" restored, and the My classes wrapping up and simplifying large chunks of the .net framework; My seems to be attempting to make .net accessible to the less sophisticated programmers,& .net novices, and reduce the amount of code that needs to be written. This prevents VB devs having to learn the framework, and will shield them from complexity, but it will become a crutch - if you're using the My wrapper, then you won't learn how to code the underlying framework equivalents. Meanwhile, C# gets refactoring support, while VB.net doesn't...

There is a certainly a movement in the 2.0 release towards more hand-holding for VB, and access to more advanced tools for C# developers. I believe this is part of a trend that will continue with the next release. MS will continue to simplify VB.net, and so it will eventually return it to its state of being a novice's language; I'm not trying to denigrate VB or VB developers (I used to be one myself, back in the COM days), but I think eventually the language will dumb itself down to the point where most serious developers will move to C#. The target audience for VB.net will be beginners, students, and end users looking to automate work-flows.

Again, I've no wish to denigrate VB - when I used to develop with VB.old & VB.net, I was always exasperated by the "C++ / C# is better" argument, and thought it unfair that C# got features that VB.net didn't (operator overloading, which VB gets in 2.0, an allegedly more efficient MSIL compiler, etc). However, the point I am trying to make is that BASIC was originally designed as a beginner's language back in the 60s & VB followed this trend by bringing development to novices; the productivity VB brought was a mix of syntax and productivity tools in the IDE, which are now accessible to C# and C++ devs (the great debugger, the forms designer, etc). VB can't serve both pro and novice developers, and so something's got to give...

Visual Studio 2005, SQL Server 2005, BizTalk Server 2006 RTM: November 7 2005

2005-06-07T17:34:00.000+01:00

Apple To Release Tablet Mac

2005-05-12T13:20:00.000+01:00

That's right - according to engadget, Apple are going to release a Tablet version of the Mac; I've talked about Tablet PC before on this blog - I really do believe that the Tablet's time has not yet come, but it will be the next big thing. Seems that, if Apple go ahead with this, suddenly everyone will want a Tablet - maybe this is the spur the concept needs to get it into the mainstream...

More Win Forms Annoyances

2005-05-12T11:42:00.000+01:00

I've just found a site describing a problem with the default control font in Win Forms that has not been addressed in Win Forms 2.0: Things They Didn't Fix in Whidbey...

Windows Forms Annoyances 3.

2005-05-11T21:04:00.000+01:00

OK, time for part 3 of my Win Forms rant. This time: Help.

First off, support for user help is heading in the right direction, but there are a couple of problems with the implementation as it stands:

What's This? help is implemented badly; you want all your help topics in a compiled help file (.chm). So, your BA will compose help in RoboHelp, and create a help topic for every control on your form; the idea being that the user will click on either the question mark icon in your form, then click the control s/he wants information on (or they hit F1). Unfortunately, in Win Forms, the HelpNavigator's SetHelpString() method (which is designed for What's This? Help) only takes a string as a parameter - the implication being that the help topic text should be hard-coded into your app or come from a resource file. This is obviously flawed, and means you have to resort to using the HTML Help API to get your What's This? help topics out of your help file.

Also, for What's This? help, you need to associate each control on a form with a help topic; of course, there's no integral way to do this as Win Forms stands, so you are forced to use the Control's Tag property to store the Help Topic ID. Again, not ideal.

The HelpRequested event - great, an event that tells us when the user requested help for our form; we can use this to get the control that the user wants help for; the event doesn't tell us this - all it gives us is the mouse position. So we need to use this data to find where the user clicked the mouse in order to locate that control. Unfortunately, this event could be fired in one of two ways: by clicking the little question mark in the form banner (the mouse pointer turns into a little "question mark" icon) then clicking on a control, or by setting focus to a control and hitting the F1 key. So, when we attempt to locate that control with the Point the HelpEventArgs provides, how do we determine whether or not the user clicked F1? I mean, imagine that the user leaves the mouse hovering over an OK button, then tabs to a TextBox and hits F1 - what help topic do we show? The one for the OK button, or the textbox? We really don't know what the user did, so we have to "guess" what topic to show. Fiddly & error prone.

I'll be interested to see how this has been improved (if at all) in Win Forms 2.0...

Windows Forms Annoyances 2.

2005-05-09T22:58:00.000+01:00

Continuing my previous post on what I don't like about the current implementation of Win Forms, I'll expand on a throwaway comment I made about MVC.

Win Forms doesn't really support MVC; the model MS favoured was the Document\View pattern, implemented in MFC, and later in Visual Basic.old. The benefits of this is that it eliminates the complexity of MVC (which relies heavily on eventing, pointers, and decouples your UI application into a user interface and an underlying object model - so good OO skills are a must).

So, when MS came to create WinForms, they pretty much took the existing VB model and development mindset and gave it a new gloss; as I said in my last post, this makes the transition for VB developers to Win Forms relatively trivial, but IMO it was a "warts and all" port; sure, there's some good stuff, but there's also a lot of nasy stuff that should really have been re-thought (see my last post for more on this). My main objection is that it is possible to do MVC in Win Forms, but by default you're pushed into the default document/view model.

So, when you come to create a Win Forms app, what do you do? First off, the IDE will put the app's entry point, Main(), in the default form (this is "fixed" in VS2005). You will then drag and drop controls onto this form, and in most cases double-click on them to add code behind the exposed events. Next, you decide you need data; so you'll make calls to a database, or web service right there in the event code in your form (or perhaps you'll show some initiative and create a class that wraps the call for data, but it really just amounts to the same thing). Perhaps some buttons or controls will navigate you to other forms; again, you'll instantiate and show those forms right there in your form's code.

Let's go a little deeper and look at two popular controls, the TreeView and ListView; in Win Forms, these are pretty much identical to their VB.old predecessors; you can quite easily add Nodes to a tree by clicking the Nodes property and using the little dialog that pops up - you can just "hard-code" the data right into the control - that's OK for prototyping, but it breaks MVC. While we're on the subject of patterns, let's take a look at the look & feel; don't like it? OK, so change the border style - oops, just 3 styles to choose from and no way to set the colour - time to subclass TreeView and use System.Drawing to create a custom border. What we should have seen here is the use of the Strategy pattern to allow new behaviour to be applied to the border property at runtime.

Why is this bad?

You end up with your form having navigation code "hard-coded" within it; in the example above, what happens if you want to add a splash screen that shows before the default form is displayed? Some nasty code in the form_load event that hides one while showing the other?
Your calls to fetch data are tightly coupled into your UI code; even if you have a separate class, a separate component, that does the dirty work of actually getting the data from a database or web service, it's still initiated from your UI (view) code.
Your forms will get very, very big and unwieldy; and it's not just about the amount of code I'm taling about - the majority of your app's structure lies in its navigation graph and how it stores and manipulates data - and if it's all in your form code (see previous two bullets) then your app is going to get very hard to maintain very quickly.

Personally, I think this is the reason why so many VB apps are so difficult to maintain, change, and debug. MS have a write-up of MVC (albeit from a web-focussed perspective), and they have (predictably) added a caveat at the bottom indicating that Document/View is superior, which is no surprise considering that Win Forms and ASP.NET both utilise it. MS produced the User Interface Process (UIP) Application Block, to address this issue and bring MVC to .net UI dev; unfortunately, the UIP was excessively web-focussed, and it was hard to apply the navigation model to a thick client application (note that two new versions of UIP will be developed for Enterprise Library, one for web and one for Win Forms).

Windows Forms Annoyances

2005-04-29T12:23:00.000+01:00

I've not yet looked at Beta2, but here's my list of annoyances with Win Forms 1.x; Win Forms in its current incarnation is like a poor cousin in the .NET world - it's like it was developed as an afterthought to ASP.NET, C# and the .NET Framework.

1. The Win Forms Designer -

it deletes your controls after you've carefully composed a form (apparently fixed in beta2); this bug alone really makes me mad! So I don't use the damn thing as I prefer to complete a task once and not every time the tools decide to destroy my work!
when you drag controls around, it adjusts the relationships of the controls to each other - so if you have neatly arranged your controls in a line, when you drag them to another location they'll be all out of alignment...
if your form code has a bug (e.g. you've got a custom control that barfs while the designer is rendering it) then the forms designer blows up - that's fine, but at least tell us the exception details and give us a stack trace so we can work out what went wrong!
Aligning controls is just too damn fiddly! It's actually easier to layout a UI design in Visio than it is to implement it in VS 1.x.

2. The Win Forms Controls

Listviews, treeviews, etc all require an ImageList control to work - just like the VB.OLD controls did! This is rubbish, as it requires you to load an ImageList at design time with all your images and bind it to the control in question - but I want to be able to use multiple resource files to hold my images and load the control directly from them at runtime! I really, really hate ImageList, and the behaviour of the control really hasn't changed an awful lot since the VB.OLD days;
All the controls work and look pretty much the same as the VB.OLD controls; this is no bad thing, as it's easy to pick up Win Forms if you have experience with putting VB UIs together; but unfortunately you have to take the good with the bad - for instance events that give you very little information other than the standard eventargs - which mouse button was clicked? In a tree, did the user click the icon, the expando button, the text...? Unfortunately, I guess we'll be stuck with this now as it's unlikely that future Win Forms will introduce breaking changes by redesigning control interfaces.
XP Theme support sucks - not all the controls support it (e.g. the spinner controls); try making a tab control take on the Xp theme... the listview doesn't support grouping... having to set the flat style on controls that support it is a dumb hack... some of the controls' borders won't take on the XP border style so you have to resort to owner-drawn controls... Application.EnableVisualStyles() is buggy (it fires a native Win32 PostMessage() off asynchronously, and if it fails to complete you'll get random
System.Runtime.InteropServices.SEHExceptions forcing you to call the abomination Application.DoEvents() to ensure the PostMessage() completes before your call to Application.Run() - aaaargh!);
How about some MVC support? And no, I do not want to use the UIP application block, as this is really only appopriate for use in web applications (and I'll fight anyone to the death who says otherwise) - fortunately MS have admitted this and are working on a new Win Forms specific implementation in Enterprise Library; but let's see support for this in Win Forms itself. It's about time the Patterns & Practises group started putting its money where its mouth is.
Why is context-sensitive help so poorly implemented in Win Forms? How do I tell whether the form's Help button was clicked or whether the user pressed F1 easily? Why can't I pull context sensitive help out of a Help file without invoking APIs (the managed interface expects you to hard-code context-senstive help in your application code and have it completely separate to your help file - gaargh!);
Overall, the Win Forms controls are just thin wrappers around the native Win32 controls, designed to emulate the VB.OLD interfaces; well, OK there are some changes, but they offer very little in the way of value-add.

I'm sure I'll come up with more soon enough. I'm looking forward to trying out VS 2005 to see if any of these are fixed or at least addressed.

VS 2005 Beta 2 Timebomb

2005-04-19T09:16:00.000+01:00

A few more points re. VS 2005 beta 2 - it has a timebomb that expires May 1, 2006 - that's a pretty wide margin, and let's hope that we don't have to wait until then to get the RTM (we've waited long enough since VS 2003 was released).

You should also note that the version available on the MSDN site is the Standard (i.e. bottom of the scale) version - no sign yet of Pro, or the other uplevel versions; I guess this is because of the way the product has changed to offer Developer, Architect and Tester versions, all rigged up to Team System (& also the way that they are changing MSDN Universal to only allow access to one of these products per subscription). Personally, I'm going to hold off downloading beta2 until they post the other versions.

Visual Studio 2005 Beta 2 is Out!

2005-04-18T09:19:00.000+01:00

If you already have Beta1, follow the instructions here for removing the bits (the order you remove things is critical). You can then install the beta 2 bits after downloading from the MSDN Sub site (you need an MSDN sub, however...).

Win Forms Nasties; or, Where did all my controls go?

2005-04-12T15:05:00.000+01:00

I've complained about Visual Studio .NET 1.x in previous posts, so I won't rehash old rants; but one bug in the IDE that really, really annoys me is when you've spent ages putting a form together only to have the IDE just zap your controls away. Pop! And they're gone. For those of you who haven't had the pleasure, when this happens it's a similar feeling to what happens in ASP.NET when you spend ages prettifying your markup only to have the IDE zap it into an unreadable splodge of text.

Well, it looks like this feature is fixed in VS 2005! Hooray to Cyrus, who explains what caused it, and how he fixed it! Nice one, Cyrus!

In order for them to accurately display what your form will look like they need us to accurately examine, decompose, and report back the meaning of your InitializeComponent method. In the past we would just depend on our potentially out of date symbol graph, but it ended up being the source of many bugs and major headaches for the user (ever had all your controls disappear? There’s a good chance it was due to that). So, in VS2005, we changed our model so that if WinForms is asking us for data we will block the foreground thread until the background thread is finished working. In effect, for this circumstance we’ve moved to the VB model. Now, in order to not give you a horrible experience where you’re asking yourself “why the heck isn’t the system responding” we will pop up a progress dialog to tell you what’s happening, why, and how long there is left. In that case we considered it important enough because in the event of us sending bad information to WinForms, we could end up corrupting your form.

Ajax is Nothing New

2005-03-17T19:15:00.000+00:00

There's suddenly a load of fuss in the java world about Ajax. This is a supposedly new way to create responsive web apps - you basically use xmlhttp from client-side script to connect to the web server, obtain data, then display it - i.e. there's no full-page postback, so it leads to more responsive web apps. Google Suggest uses it to fetch search suggestions as you type.

But hang on a minute - we've been able to do this for at least the last five years; & it's not just a java thing - MSXML gives us this capability, as does the Web Service Behavior. ASP.NET 2.0 will support it, too, and the emitted html and script will apparently be cross-browser compatible.

Basically, "Ajax" is just a new name for old stuff. I guess by wrapping this up with a new buzz-word it will begin to hit the mainstream, and so you'll see more sites using it. It does make web UIs more responsive, especially where you're creating data-centric applications and users are keying in a lot of data. Unfortunately it leads to a phenomenon I call the "JavaScript Fat Client", where you wind up with more and more UI logic in the client-side script (because it improves performance), so you lose your nice thin client. It also masks a fundamental flaw in some apps: if you need a fast, responsive UI where the user is keying in & retrieving shed-loads of data, then the app should be a thick client, not web pages.

"Ajax" is nothing new to web devs in the Microsoft world; we've been using it for years to get around the problems of creating a responsive UI with web pages. In fact, we've already moved on to Smart Clients - the real next big thing. Trouble is, I don't think java can really do smart clients, hence the need for them to cling to web UIs.

VB6 and The Evil Dead - "JOIN USSSS"

2005-03-14T21:16:00.000+00:00

I saw The Evil Dead last week for the first time. In the film (as if you didn't know) a group of youngsters take a holiday in a deserted log cabin, which just so happens to have been the former home of an occultist. Obviously, lots of bad things happen; just when you think someone's dead, they come back to life as a hideous zombie hungry for blood, and have to be dismembered to finally put them to rest.

The reason I mention this is that at the end of this month (March 31), VB6 comes to the end of its "mainstream" lifecycle. It will then enter an "extended" phase, which is the limbo all products experience before they finally go up to the bityard in the sky.

So VB6 is dead...

Wait! What was that noise?! No, it can't be! VB6 stirs, the lips part and cry "JOIN US!!".

Yes. A group of VB6 developers (including a bunch of MVPs) have started a petition to keep VB6 (or VB.com as they've chosen to call it) alive. If they get their way this decaying abomination will live on in VS.NET side by side with C# and VB.NET.

Why? Because these developers have decided that the step to VB.NET is a step too far. After years of crying out for a proper OO language and full access to the underlying OS (without having to rely on esoteric API calls), these devs have rejected VB.NET. They want to keep VB6, warts and all.

In the movie, a variety of tools (chainsaws, knives, axes, shotguns) are used to dispatch the walking dead and to put them to rest. Ignoring them is not an option. Fortunately, in the case of VB6 ignoring it is the only option. Eventually these devs will realise that VB6 really is dead. They may get angry, say they'll drop MS technologies; but where are they gonna go? I mean, to Java? If they can't handle VB.NET then they ain't gonna get on with Java. Maybe one of these smart guys will invent a time machine and return to 1991.

"Join us"? Get outta town!

Datasets...

2005-03-14T18:00:00.000+00:00

I had a go at Datasets on a previous post a while back. My main dislike of Datasets are that they're non-OO, and generally quite slow (especially when using them to transport data between tiers). Another problem I have with them is that MS tend to push Datasets as if they're the only option - there's not much in the documentation about using custom collections and objects instead of typed / untyped Datasets.

Seems MS have published an article deriding Datasets in favour of "custom entity classes". This is long overdue. Most devs take to Datasets because they're easy to get up and running, with the result that object-orientation (and a more elegant, efficient solution) is overlooked. Object orientation is not just about creating classes with properties and then using them (even VB6 had this "class-based" approach): it's a different mindset altogether. I see the abandoning of Datasets to be an essential first step for MS developers seeking to reach out towards proper OO ways of thinking and developing software.

IE 7

2005-03-10T00:47:00.001+00:00

Looks like MS have been working on IE7 for at least four months already. As is well-known, the IE team were pretty much disbanded after IE6 was released, and the majority began work on "Avalon" (this is why IE has since stagnated and lost market share to Firefox) . Looks like some of them, including Chris Wilson (who was on the IE team between 1995 and 2001), have now gone back to IE development.

It sounds like MS are going to be making a big push towards standards support in IE7, in a bid to get web developers back on side. What drew me to IE in the first place (back in '96) was that it was just so much easier to develop for than Netscape; when I saw IE3, I immediately dropped Netscape and have never used another browser since (despite a very brief flirtation with Firefox). It's also the reason most intranet sites are written for IE - why spend loads of time and money on cross-browser compatibility when you can control which browser your users have? Despite recent criticism, for a long time IE was light years ahead of Netscape in terms of standards support (DHTML, XML, CSS, and so on), but then things just died off after IE6...

So, now we know that IE7 will have much improved security features, and improved standards support; we know that they will maintain backwards compatibility for the sake of all those websites out there that depend on IE's quirks to function (it will be a different story under "Longhorn", though).

If my reckoning's right, I believe that IE7 will have:

UI enhancements; they've made it clear that adding tabs was not an easy addition to IE, so perhaps they've completely re-written the shell - unlikely, but it's possible that the "Longhorn" browser has been backported to XP, and utilizes the existing IE rendering engine, which is where the backwards compatibility would come in. So worse case scenario is tabbed browsing and a new security options page in the UI;
It may even have portions of, or at least hooks into (to provide an upgrade path), "Avalon" code; remember that "Avalon" will be available on XP - "Avalon" utilises XAML, and a means to render this is required sooner or later on XP;
Anti-spyware (based on their new Anti-Spyware app) and anti-phishing security features;
Developer-friendly standards support.

XAML Part 2.

2005-02-24T22:07:00.000+00:00

Ok, what is XAML and what does it look like?

XAML defines an application's UI, with tags representing standard Windows controls and attributes representing their properties. Nothing revolutionary there! Here's a simple XAML page:

<Canvas xmlns="http://schemas.microsoft.com/2003/XAML" ID="sample">
     <Label ID="exampleLabel1" FontFamily="verdana" FontSize="8" Canvas.Top="10" Canvas.Left="10">This is a label's text!</Label>
     <TextBox ID="exampleTextBox1" FontSize="8" Canvas.Top="8" Canvas.Left="75">This is some text in a TextBox!</TextBox>
     <Label ID="exampleLabel2" FontFamily="verdana" FontSize="8" Canvas.Top="35" Canvas.Left="10">Another Label control</Label>
     <TextBox ID="exampleTextBox2" FontSize="8" Canvas.Top="33" Canvas.Left="75"></TextBox>
     <Button ID="exampleButton" Width="50" Canvas.Top="60" Canvas.Left="155">OK</Button>
</Canvas>

Note that the example above is based on the original "Avalon" preview - I haven't had chance to check out the latest bits, but note that the schema namespace is http://schemas.microsoft.com/winfx/avalon/2005 in the latest release.

Each XAML page consists of a root panel element (a Canvas in this case) that contains nested controls, such as Labels, TextBoxes, and Buttons. "Avalon" deserializes these elements into live object instances of strongly-typed controls, using the attribute values (such as ID or Width) to set the object property values. Note that positioning is handled by the strange Canvas.Left, Canvas.Top construct; these are known as "extended attributes", and elements inherit these because they are nested within a Canvas element. This is strikingly similar to the way "expando" properties work in IE (you may have used them when using DHTML Behaviors); but that's no coincidence - the IE team members are heavily involved with "Avalon".

Each XAML element corresponds to a class in the "WinFx" release of the .NET framework. When the application runs the XAML markup is deserialized into objects by the runtime; markup elements become object instances, and properties are set according to the values defined in the XAML elements' attributes. The concepts involved are exactly the same as how you serialise and deserialize objects to and from XML using .NET 1.x today.

The root element of all XAML documents is one of the subclasses that inherit from the Longhorn Panel class. There are several different panels that provide positioning and layout services. If you create a XAML Application with the Visual Studio.NET "Whidbey" alpha on the "Longhorn" preview, it creates a default Canvas panel, which provides something similar to absolute positioning in Web pages or the standard positioning model in Windows Forms.

Just like a web app, a XAML application is made up of pages. A .proj file groups the pages together into an application, and in addition to containing information about each XAML page, also specifies compiler settings, such as version info. It also controls whether the app will run in the browser (i.e. run from the server, like a web app), or be displayed in a window (i.e. installed to the client, like a thick client). An application definition file defines the application's navigation model and application-level events. If you're familiar with .NET, then you should be seeing shades of ASP.NET and Win Forms development by now... but a subtle combination of the two...

More soon... inlcuding some info on "rival" application markup initiatives... and some products that allow you to create XAML applications that run on .NET 1.x...

If you need more info on any of the above (keep in mind that "Avalon" is still under development, and anything can change until it ships!), please see the MS "Longhorn" SDK site, which contains all the publicly available info on "Longhorn", "Avalon" and XAML.