I'm not sure when this was added (if it's just in VS 2008 or if it's been there since VS 2005), but I just noticed this while I was updating the website (I just added a download section). I created a new master page for the site, then updated the original home page with one that used the new master page. The master page is now home to the header, menu, and footer with a "hole" punched in the middle for my custom content. Then I added the download page and started adding files. You might not have noticed before, but the home page has a footer which moves with the browser; it basically sticks to the bottom by using a bit of CSS. This works well on the home page, and appeared to be OK while I was working on the download page. That is. up until the number of downloads forced the page to scroll. At that point the footer actually sat on top of the downloads listed, which isn't quite the effect I was hoping for. If I changed the footer style to float, it worked well for the download page but was pretty ugly for the home page (since it's a bit sparse the footer was like 1 inch below the header).

I played around with the idea of embedding a div tag in my home page that had relative heights to force the content back to where it belonged. That didn't work out too nicely, so I briefly thought about using JavaScript to handle this instead. That seemed like overkill, so I nixed that idea. If the footer was defined in my home page content section, I could just override the CSS style for that one page. However, it's in the master page. I could define two CSS files instead, but I really didn't like the idea of having to maintain two stylesheets. That's when I noticed a new section in my master page - a content holder for the head section of the page:

That made it really simple to just add an overriding style (with the same name as the one defined in my CSS file) into the home page content. I had to move the CSS link above the ContentPlaceHolder so that it was defined before my overriding style. Then I just added a <style> section inside of the header and I was good to go. This isn't earth shaking stuff, but it was a nice addition.

I ran across this in the comments section over at Coding Horror:

"I'm bitter, angry and I hate you all. Isn't that proof that I've worked in the software development industry for a long time?"

Links

http://www.codinghorror.com

I mentioned in a previous post about signing up for the Microsoft Empowerment program. At the time, they mentioned it may take a while to hear from them. I figured I'd get at least a "hey, we got your application, thanks" e-mail. So far, not a thing. It's not really clear on how (if?) I can even check the status on this.

This was the original signup link: https://partner.microsoft.com/40011351 (strange, my original post should have had this link as well - I wonder where it go lost).

I just checked it again and they mention that the site is undergoing maintenance from 11/8 - 11/30. Great - I wonder if my application ended up in a black hole. I was really hoping to have the licenses taken care of by now, since some of my MS software demos are about to expire.

I thought it might be fun to convert an old VFP app. I wrote when I was playing around with web services inside of VFP to work inside of Visual Studio. It was a simple program which connected to a webservice which serves up a new Dilbert comic every day, then it displays it in the VFP desktop. I've been thinking about doing it for a while - my initial thought was to modify and/or customize the RSS feed which Visual Studio uses to display it's latest news. Unfortunately, I couldn't figure out how to get it to display images - it seems to reformat the feed and strip out any of the markup. A bunch of googling didn't turn up much either.

I briefly looked at the Visual Studio SDK a while back but the licensing cost was prohibitive (something like $10K). I could use it for development and on my machine, but I wouldn't be able to distribute it w/o the license. However, Microsoft just recently changed all of that with the latest release;  ran across this via Code Magazine's Focus issue on Visual Studio Extensibility. You can download the magazine for free from: http://www.code-magazine.com/focus/Index.aspx. I downloaded the SDK and got it installed with VS 2007 Beta 2 (yeah, yeah, VS 2008 was just released). Then I kind of lost momentum and didn't do much with it.

This morning, while I had a bit of dead-zone time (that's the time between interruptions that you KNOW are going to occur on some days, and they're going to be spaced so close together that it's not worth getting involved in anything too mentally strenuous). I ran Visual Studio Integration Package wizard and had a stub project up in running in a few minutes (I picked the "Tool Window" option). It creates a MyControl.cs form with a button on it, so I just deleted the button and added a PictureBox in it's place.

Then I just did almost a straight port of my VFP code which checks to see if it's already downloaded the comic (and if so, it checks the dates to see if a newer one should be available). If necessary, it downloads the file and dumps it into the PictureBox. They've set things up so you can just "run" this project and it will automatically start up a new instance of VS to test in, which is really nice. If you've never used a web service in VS, it's really simple - add a reference, enter the address of the web service and it builds a nice simple wrapper class for you. I guess I could have done this via WCF, but I really didn't want to complicate things.

My first test seemed OK - I selected View > Other Windows and picked my new Dilbert A Day option. The toolbar window appeared with the latest comic - so far, so good. It docks like any other VS tool, so I docked it to the bottom of the screen. I closed my debugging instance of VS and restarted it to see if it still worked. Nope. No image. I ended up having to move the code which downloaded the new comic out of the control and into the class which instanciates the form (MyToolWindow.cs). Once I had that working, I decided it really needed to have a custom Dilbert icon. I snagged an image from the Dilbert site, cropped it and resized it down to 16x16. There are two resources embedded in the project which include a strip of icons. I was lazy, so I just replaced the second icon (which seems to be the default selected inside of the pre-generated code) in both of the BMP files.

Here's what it ended up looking like docked at the bottom of VS:

Here's it expanded:

And the new menu option:

I'm pretty happy with how this came out - this took me literally 20 minutes to put together. Granted, this is hardly a taxing application - I could easily be swearing at the SDK if the example were any more complex. But they at least did a nice job to help get you up and running pretty quickly.

OK, I admit it, this post is a bit of a tease. I had hoped to get this posted as a installable component w/source tonight. I figured I could get the installer working (ideally as a "ClickOnce" app, since this gives me an excuse to play with that, although I'm not even sure it can be deployed this way) relatively quickly. However, once I started looking at what was necessary for deployment I came across the fact that I need to get some sort of Package Load Key (PLK) from Microsoft, which requires me to sign up for the Microsoft Visual Studio Industry Partner Program website. That's actually pretty painless, and it looks like they've got a simple interface to request this key:

At that point, it wants me to answer a bunch of questions about the download location, product logo, etc. that I wasn't really ready to deal with. The final deployment aspect of all of this also seemed to be missing in the docs I've read. I ended up having to do some more digging through the Code Focus issue and came across this link which has a video which covers deployment (yeah!). I'll have to watch the full video (it's around 20 minutes) before I can finish this thing up.

I'll follow up with that in another post, along with a bit of code from the project and maybe a simple comparison of the VFP code vs the .NET code. I guess I'll also have to put up a downloads section to make it easier to find all of this stuff, especially if I need to provide all of that to generate a PLK. Let's hope this 20 minute quickie project doesn't turn into some huge odyssey - unfortunately, that seems to happen a lot in development, doesn't it?

Links:

http://www.code-magazine.com/focus/Index.aspx 
http://msdn2.microsoft.com/en-us/vstudio/aa700819.aspx
http://www.vsipmembers.com/
http://msdn2.microsoft.com/en-us/vstudio/aa700829.aspx

It looks like XSource for VFP 9 SP2 is now up on the Microsoft website:

http://www.microsoft.com/downloads/details.aspx?familyid=320b6438-be76-48c7-a68e-1792e2aa3bf2&displaylang=en

The interesting thing about this is that it's now licensed under the Microsoft Permission License so you can now distribute it or your own custom modifications of any of the tools included in it. This is basically all the source code for things like the DataExplorer, the Report Builder/Output/Preview controls, the Task Pane, etc.

Reporting bug in VFP 9 SP2

Cathy Pountney has an article regarding a new bug introduced into the reporting engine in SP2 using grouping and group headers.

http://cathypountney.blogspot.com/2007/11/gotcha-serious-report-bug-with-data.html

This falls into the "hey, I didn't realize this was available" category. In the 2.0 version of the .NET framework, support was added for nullable types, I'm guessing primarily for improved interaction with databases. Previously, nulls were a real pain to deal with; now they're only a bit more work (the pains not completely gone, but it's not as bad anymore). Lets say you've got a date time field in your database, it can have an actual date filled in or it can be null. In prior versions, you had to rely on "magic" dates to do translations when loading and saving your data (eg. 1/1/1900 is really null). Now you can just define a nullable type by prefixing the type with a question mark ?

That's not the point of this post though. They've added a nice operator ?? - so let's suppose I've got a calendar control that returns null if no date has been selected. I'd like to default to the current date if that's the case. I can write code like this:

Or I can use the ?? operator:

That's much simpler code to understand (at least to me). I like this a bit better than the normal ternary "if" support, which I always find a bit difficult to read:

The question shouldn't be, "Can we do this?" but, "Should we do this?".

I think companies sometime get so excited about the possibility of doing "X" that they forget to ask themselves if it's something that should even be done:

• What are the risks?
• Does the payoff justify the amount of work required?
• Are there more important things that should be done first?
• What is the simplest way of accomplishing our goal (it may not even include doing "X")?
• Is this our core business or should we look to an outside source?
• Does this even make sense?

I've been using Subversion along with TortoiseSVN (and VisualSVN inside of Visual Studio) for a few months now. It's been relatively painless, up until recently when I've attempted to really start using it for more than the standard "make changes, check it in". Unlike Visual SourceSafe where you check out a file and it gets locked until you check it back in (which is just the default; it can actually be changed to allow shared checkouts), Subversion lets everyone use all the files all the time, then merge on check in. I haven't attempted to try Subversion with any of my VFP projects yet, it's been strictly the .NET applications, so I haven't had to try to deal with merging the binary files created by VFP (eg. for forms, the SCX and SCT files, or for classes the VCX & VCT files). If you're enterprising, you can try out TwoFox from Christof Wollenhaupt. I'm leaving that hill for another day.

I ended up moving around my repository to support the more standard folder structure, since I didn't do this when I first started out. So my folders are now in this format:

branches
tags
trunk
  |--Project A
  |--Project B

The other suggested route was to put the branches/tags/trunk folder inside the project folders themselves, ex.

Project A
  |--branches
  |--tags
  |--trunk

This looked a little too confusing, especially since most of our projects are build into a single solution. To move everything around, I opened TortoiseSVN and went into the repository (right-click in Explorer, select Repo-Browser). Then I navigated to where I had my .NET development stuff, \Server\DotNetDev, right-clicked and selected Create Folder. I created the branches folder (which is meant, strangely enough, for any branches in the source code), then created the tags folder (this is equivalent to a label in VSS, although Subversion doesn't make a distinction between a branch and a tag), then the trunk folder (which is meant to hold the primary set of source code).

Then I dropped down to a command prompt and moved everything from it's original location to it's new location:

svn move -m "Relocating Project" svn://Server/DotNetDev/Project svn://Server/DotNetDev/trunk/Project

I kept the Repo-Browser open and hit F5 to make sure the change took place (it did, so far, so good). The rest of this didn't go so smoothly.

I needed to point my local copy of the source to the new repository location. It turns out there are two different options to do something like this: Relocate and Switch. I thought I might want Relocate, so inside of TortoiseSVN I right-clicked on my DotNetDev folder and selected TortoiseSVN > Relocate. Here are my notes of how this went:

- Immediately see scary message about me doing this, did some Googling, decided I really DO want to relocate.
- Get another error about it not being the root. Decided to try Switch instead.
- Get another error about one of my projects not being in the same repository.
- Realize I may have mistyped the new repo. name, try svn://Server/DotNetDev  to svn://Server/DotNetDev/trunk instead.
- Get errors about it not existing in that location for that revision.
- Great.
- Select the option to Update to Revision.
- Suddenly panic that I'm going to lose my changes that haven't been checked into source control yet. Wish I had thought to make a backup first.
- It doesn't seem to help.
- Realize I had one folder which still pointed to it's original source on the web (I'm using an open-source project that I had grabbed via TortoiseSVN, so it's still pointing to that website)
- Try to relocate it and get errors about relocating only changing the repository part of a URL (regardless of what I try to change)
- Get irritated and go to lunch.
- Get back from lunch.
- Delete the .svn folder that was pointing to the wrong server (the open source one).
- Make a backup of the directory where the .svn folder was.
- Get new version via SVN checkout for that specific folder.
- Try to use Switch.
- Get error about needing to cleanup the project.
- Cleanup.
- Try to use Switch again.
- Get a different error about some file not being able to be added to the repository because it already exists (it's the same folder I've been having problems with).
- Erase the entire folder including the .svn folder this time.
- Do a checkout on this folder again.
- Finally get around to making a backup of all my files, just in case.
- Try Switch again, it seems to do something and not give any errors.
- Ran a diff on the folder I had problems with to check to see if I lost anything and/or grab files from my backup.
- Fire up VS and force a rebuild to see what/if anything was broken.
- All good (!)

Relocate = Source is switched to a completely different server.
Switch = Source is on the same server in a different directory.

I'm not entirely sure why these are two different options.

Fast forward two weeks. I decide to test out the idea of creating a private branch where I can make all my daily changes (and do a check in at the end of the day). I basically don't want to check in stuff that isn't complete, may break things for other developers, etc. But I want to make sure it gets checked in daily so it's backed up. Branching seemed like a good way of handling this. The initial branch seemed to go smoothly so I made changes over the next week or so and kept checking them in. Today I decided to merge the branch back into the trunk so we could get a good copy of the files on another dev. machine. It seemed to go about as well as moving the repository (I'll spare you all the ugly details).

Ultimately, I think the problems were related to the fact that I had a completely different mental model of how merging a branch should work: I though you would just select the option to merge, then select the branch you want to merge from (my local copy) and select the branch you want to merge to (the trunk), let it merge and resolve any conflicts (if any). The UI even looks like this is how it should work. It doesn't.

I must have tried merging 20 different times, each time with different errors or issues. I read and re-read the docs and just didn't seem to understand how this was supposed to work. Here's what finally worked for me:

I had to check in all of my changes into the branch I had been working with, then use "Switch" to switch back to the trunk copy (which does some scary things like delete source code in your local copy). Once I had a copy of the trunk, I did the Merge again, pointed the "From" option in TortoiseSVN to the trunk, not my local copy. Pointed the "To" to the branched copy I had been working on. Then I selected the last revision before the branch in the trunk and all of the revisions in my branch, and it seemed to merge OK. Then I committed my local copy back into the trunk.

It appears you need to track the revision numbers manually (the check-in notes are probably the simplest) when merging branches back in; so, for example, if I had revisions 50-55 in a branch which I then merge into the main trunk, then make changes 56-60 in the branch again, I have to make sure I only merge revisions 56-60 into the trunk. Otherwise, I risk duplicating changes (essentially, Subversion doesn't track your merges). I looked at the roadmap and it appears that functionality is scheduled for build 1.5 (it's currently at build 1.4.5). That's definitely going to be a welcome enhancement.

One thing I noticed in the docs is that they mention that new Subversion users have problems with the From/To issue, and with picking the correct revision to merge against. It's pretty clear they're forcing users to deal with implementation details that I think should be hidden, so that the mental model most of us have of all this actually matches what we need to do in the UI to accomplish things. Having to mention that most developers make mistake "X" or "Y" should be a red flag that maybe things need to be changed.

The one saving grace of all this is that I haven't lost any changes yet. I'm starting to get in the habit of checking all my files in before I attempt to do anything out of the ordinary (which seems to be a good practice to get into).

Links

http://subversion.tigris.org
http://tortoisesvn.tigris.org
http://www.visualsvn.com
http://www.foxpert.com/downloads.htm

One thing I've learned while using SQL Server is (whenever possible), perform as much as you can on the server. That means either stored procedures or SQL commands passed up to the server. It also means thinking about problems as sets, as opposed to a more procedural approach. Visual FoxPro makes it easy to blur the lines between SQL commands and normal procedural code (mixing and matching as you'd like), so you tend to start getting locked into thinking about data on those terms. While some of this translates directly to SQL Server (obviously, the SQL language itself), other things don't.

I recently decided to add a new foreign key to a table; the structural specifics aren't particularly important so I won't go into too much detail about them. Essentially, I had a parent (A) and child table (B). There is a posting process which takes a snapshot (C) of some or all of the records in the child table for a specific parent. This snapshot includes a foreign key back to the original child record but didn't include a foreign key back to the parent (since it could be derived by joining to this child table). I began to realize that, because of the number of records involved (it could be as many as 250,000 records in the child (B) for a single parent record (A), which meant up to 250,000 records in our snapshot table) that most of the queries were really slow because of the extra hop involved in resolving this parent key. So, I decided to go ahead and add a foreign key into the snapshot table (C) to the parent (A). That also meant I needed to go back and fill in the new foreign key in the Snapshot (C) table.

In VFP, you might just open the tables, SCAN through the Snapshot (C) table, do a SEEK into the Child (B) table for the foreign key back to the Parent (A) table and save it into the Snapshot (C) table. That works OK if the tables are local, what about with SQL Server? I guess you could take the same approach; pull a copy of the records from the Snapshot (C) and Child (B) tables locally, index them, then run through the same SCAN loop (or if you're really old school, set a relation and just do a REPLACE). But how long will that take - remember we're talking about pulling down up to 250,000 records in the Child (B) table, plus another 250,000 records from the Snapshot (C) table, then updating all of the records in Snapshot (C) table. Multiply that by the number of master records (in my case, only 20-30 of the master records had anywhere near 250,000 records but we're still talking millions of records).

Suddenly the above approach doesn't look like such a good idea. Thankfully, SQL includes provisions in the UPDATE command to do exactly what I wanted to. It would still take a while to run (I clocked it around 25 minutes), but it was a significantly better solution than a SCAN loop. Here's what the query ends up looking like:

UPDATE Snapshot
   SET Snapshot.fk_Parent = Child.fk_Parent
  FROM Child
INNER JOIN Snapshot
    ON Snapshot.fk_Child = Child.PrimaryKey

So what does this actually mean? We're basically saying, inside of our Snapshot (C) table set our new foreign key equal to the Parent (A) foreign key in the Child (B) table. The FROM/INNER JOIN defines how to match the record in the Snapshot (C) to the one in Child (B). Simple and fast.