Tone's Notes

New Mexico Skies offers a fully equipped astronomy vacation experience. They have a variety of telescopes and provide accommodations. If you have a basic idea of what you’re doing, you can have the run of one of their telescopes after you pass their operator checkout.

iBisque adds even greater access by providing internet browser based control of the equipment. Pricing for this option seems to be geared towards bulk time allocation and there’s an implication that time resellers might exist.

This could be a very cool way to get first hand confirmation of what’s up there…

Downloaded the latest DasBlog beta distribution (assemblies pre-built).

It was very easy to bring up compared to Dottext due to the lack of a database configuration. Not using a database has advantages and disadvantages.

The key steps were:

Download the 1.6.4107.0 beta zip
Unzip to a new empty folder (no previous content, themes, settings added)
Use Properties->Web Sharing with alias 'dasBlog' & default permissions.
set default.aspx as the default document
add local ASPNET, IUSR_, and IWAM_ accounts to root folder with default / read permissions)
give local ASPNET, IUSR_, and IWAM_ accounts write access to content, siteconfig, and log folders.
Login with admin/admin

Edit the siteconfig\siteSecurity.config file to add user accounts.

Updating a posting via the SimpleBlogService was eliminating all categories and making the title link disappear.

The implementation of  Update in DataDTOProvider.cs expects the entry’s PostType property to be set and it wasn’t. This resulted in a CategoryType of StoryCollection being used where PostCollection would have been correct. The correct thing to do would be for Entries.GetEntry and Entries.GetCategoryEntry to correctly initialize the PostType property.

Since this wasn’t happening, I force the PostType to BlogPost in the Edit method of SimpleBlogService.

To correctly update the categories assigned to a post and prevent the assigned categories from being erased I added an overload for the Edit method that takes an array of category strings.

If you’ve ever looked into the implementation details of CollectionBase, especially the IEnumerator support, or wondered why ICloneable appears to force you to return an object from Clone, you probably discovered Explicit interface member implementations which allow you to define a weakly typed method to satisfy the interface while also defining a strongly typed method.

I’m one of those people who doesn’t type “private” in front of every class field and method since I know it’s the default access modifier.

So when I see something like the following I assume it’s a private method, but it’s actually public in the sense that anyone with a reference to one of my objects can call it.

int IList.Add(object card) { return list.Add((Card) card); } // This method is public

Anyone can call the IList.Add method on one of my objects by using a cast to get at the IList interface. E.g.

CardCollection cards = new CardCollection();

((IList)cards).Add(someObject); // invokes what you may have thought was a private method.

If you consider that all interface methods must have public access, this makes sense and is desirable. I found it confusing that it is a compile error to put a “public” access modifier on an explicit interface method implementation. The default access modifier is private, and yet in this case the behavior is public.

If you simply implement a method that matches the signature of an interface method without using the explicit interface member syntax, you must explicitly declare it “public”.

WeWantWorkBoston.com is a site of senior IT talent looking for work...

I came across the following reference while looking for a definitive statement on WHY the documentation says that you MUST follow the EventHandler / EventArgs pattern when declaring events and their delegates.

Here’s a good list of design issues with .NET. It’s not a new list (seems to be 2002 to 2003 vintage work) and unfortunately most of the points are still valid. Good reading for anyone doing software design against .NET. Reminds you of when the pain your feeling is due to other people’s design mistakes and the features you should avoid or compartmentalize.

Okay, so who out there knows what pain will follow breaking the recommended EventHandler / EventArgs design pattern?

As far as I currently know, it’s purely a convention and motivated by an ill-defined intent of being general enough to handle all possible event data signaling requirements with a fixed set of parameters.

There doesn’t seem to be any compiler or debugger issue with using any combination of arguments you like for your delegate.

I’m guessing the designers figured events have a way of wanting to pass more information back to their clients over time and we don’t want our users’ code to break everywhere when they change their parameter list. So let’s train them to use derived classes to hold the actual parameters and then they’ll be in a good position to add more data through derivation without breaking clients who don’t care.

The drawback of this approach is that most times you have to experimentally guess what the actual type of the “sender” will be and whether it will ever be null or not. The same goes for the EventArgs derived parameter ever being null. The rule is return a default constructed EventArgs when you don’t have any data to include.

The thinking must be that someday in the future, you’re event source will start returning an EventArgs derived object with interesting data in it. You’ll then start writing client code that expects the argument to be non-null and of the derived type. If you completely fail to code defensively when accessing the parameter, your new client code could break if it ever runs against old event source code (which might return null). Seems like quite a stretch.

The Excel SERIES function can’t directly use the OFFSET function but it can use names defined using the OFFSET function.

I guess SERIES isn’t technically a function, it certainly is hard to find good documentation on it.

A useful site for figuring things out relating to Excel charting.

My first approach to inserting a new row of data into an existing Excel worksheet from an executing C# assembly was to use the interop assembly generated from the COM Microsoft Excel 11.0 Object Library.

I was successful in creating an application, opening a workbook, getting a reference to the worksheet and updating values in existing cells; but I failed to find a method for inserting a new row. The documentation for the automation interface is poorly organized and I may just have missed it.

My second approach was to use System.Data.Odbc. By assigning a name to the worksheet data range I knew that I could read and write data to the worksheet. The advantage of this approach is a looser coupling to the Excel document. So long as the named range and column names are unchanged, the code should continue to work.

Here are the “issues” I ran into before getting this to work:

·        The connection string must include a “ReadOnly=0” clause or you’ll get an exception with a message of “Operation must use an updateable query”. E.g.
Driver={Microsoft Excel Driver (*.xls)};DBQ=c:\Tone\Notebook\Data.xls;ReadOnly=0

·        The SQL query editor accessed through the Server Explorer of the Visual Studio Enterprise and Universal editions mis-parses column names such as “[Weight in pounds]”. It adds spaces before and after the braces resulting in a syntax error when you rerun the command.

·        The ODBC data type of an Excel column assigned a date format becomes OdbcType.Timestamp which isn’t convertible with a System.DateTime. Instead of using Parameters, I had to resort to String.Format with a format string of {0:yyyy-MM-dd hh:MM:ss} in single quotes for the DateTime.

·        I tried using the OdbcCommandBuilder to generate an Insert command for me to see how it handled the Timestamp column but couldn’t get it to generate them. Even after filling a DataSet using an OdbcDataAdapter, changing a value and calling Update, only the original Select statement appeared to be valid. By now I’m way over budget on getting this to work, so I’m leaving this mystery for the future.

The flag enumeration values shared by the blog_Content table trigger hadn’t been updated which resulted in the stats not being updated (PostCount, CommentCount, etc.)