This was my first time in Stockholm, and was literally fascinated by this Northern capital, by its old town, with its narrow streets crowded with people (and tourists) and its modern neighborhood that are a delight for go-shoppers. But I can’t forget I am here to attend VBITS, held on May 21-23 at the Stockholm Fair.
This edition is a bit special for us at VB2TheMax, because three members of our team In another room Dino was teaching about Monitoring File System Events with VB6. File notification objects are a feature of Win32 since the very old days of Windows 95. You can use them with VB and it doesn’t prove to be particularly hard. However, once you’ve understood the key of the technique, you might want to do more. This is where the Win32 notification interface shows all of its structural limitation and where an object-oriented framework proves to be extremely useful. If you’re a smart and brave C++/NT programmer, chances are that you successfully use the full notification API. If you’re only a brave VB programmer, you’ll certainly enjoy the .NET object model to keep under
control the file system activity. Dino provided a practical demonstration of this.
He started by illustrating with plenty of details how to make calls to the Win32 functions responsible for notification events. Better yet, he delivered an all-encompassing class for a very quick integration with new applications. A few creative and real-world demos completed the first part of the talk where people saw in action a reproduction of Explorer – that is an application able to detect changes in the file system and automatically update the user interface. Dino demonstrated that this works for databases too and irrespective of the programming tool you use: ADO scripts, VB application, Access itself. Finally, he touched down on the land of what’s-not-so-good with notification objects. You never know, for example, what is the file(s) modified. The Win32 API provides this extra (but key) information only under WinNT/2000 and by the means of an additional API full of weird data structures and pointers. Just the kind of thing you’d love to call even from C++. When the disappointment seemed to be inevitably mounting, with a pleasant coup-de-theatre Dino jumped to the .NET Framework to show how handy and easily understandable the new OOP interface for notification objects is. A full demo of the .NET FileSystemWatcher class completed this very in-depth and thoughtful session.
In his next session, Hardcore Registry Manipulation with VB6, Dino explained that in VB you natively see only a small portion of the registry. Nothing new and nothing better. API functions are callable from any VB application but more often than not they turn out to be a rather inextricable forest of arguments and type-cast pointers. Not stuff for VBers.
Dino showed how to significantly smooth the difficulty of making calls into such functions by resorting to multiple prototyping. At the Win32 level, to read a value from the registry you use always the same function regardless of the actual data type. Thought for C/C++, this is not particularly hard as you just cast a pointer to the type you want. This can be elegantly done in VB by declaring different prototypes that differ only for the particular type used in a certain formal parameter. Of course, make sure that the size in bytes you put on the stack is always the same.
Dino answering post-conference questions
Dino’s last session was entitled Ad-hoc Data Reporting in ASP.NET. A huge percentage of Web applications follow a very simple schema: they fetch data out of a data source, format them into a friendly layout and forward this HTML-based code to the user. In doing so, the most powerful tools you have, the better. ASP.NET comes with a variety of server controls to help you building grids of data effectively and quickly.
In this talk, Dino discussed the DataGrid Web control in almost all its facets. The basics attributes to set, the structure of the grid declaration, the countless possibilities to customize the user interface – from graphic styles to sorting, from pagination to templates. A step-by-step series of samples completes this session that terminated with a list of things to change in the supplied code to meet the requirements of .NET Beta 2.
Compared to Dino and Francesco, Jimmy Nilsson is more of a newcomer, but such a promising one. His session Tune COM+ N-Tier Apps for Performance and Scalability was packed full with practical tips that I could use directly in my ordinary design and programming projects. He started the presentation with a demo inspired by a real-world problem that he inherited from a group of die-hard Java and SmallTalk programmers, who had created a too orthodox object-oriented design. To fetch all the orders for a specific customer and present that on screen, they had used almost 200 server-side objects. It took roughly 40 times longer than Jimmy’s tuned solution with only two server-side objects, where he had focused on the transactional design instead. Jimmy continued the presentation with several tips, some heard before and some was totally new to me even though I thought I mastered COM+ tuning. Several of the tips were more focused at the database than what is common. Jimmy had prepared the presentation so that he ran all the demos physically over three tiers. Well done! The finale of the presentation was a demo of the new COM+-possibilities to VB-developers that VB.NET exposes. Jimmy showed how to use COM+ object pooling for a serviced component in an interim-version of beta 2 of VS.NET. It looked much nicer than beta 1. Guess if I wanted to get beta 2 after that!
Of course, there were many other compelling sessions this year at VBITS Stockholm, and I had to make a reluctant choice among the many available, most of them by seasoned, internationally known speakers. There is no enough space to list them all, but I’d like to remind Bill Vaughn’s ADO Performance Optimisations. If you never attended Bill’s presentations before, you’ve missed something! They aren’t only informative and in depth, Bill is also even funnier than in his writing.
Brian Randell’s From COM to the Common Language Runtime
