Monday, May 21, 2007

Business Decision Regarding VFP?

I've had a number of people ask me recently about my position on the announcement that there will be no future versions of Visual FoxPro. Of course, this hardly comes as a surprise. The writing has been on the wall for years. I disagree that this was a business decision made by Microsoft. I believe this was a decision made years ago at Microsoft and that it was driven by egos, not business. Personnel decisions excluded, I'm not sure Microsoft has made a sound business decision related to VFP since they acquired it, unless the decision from day one was simply to kill the market. In that case, my hat is off to Microsoft. They can declare "mission accomplished" in the VFP market place in much the same way George Bush did in Iraq and with equal credibility. In reality, what's done is done and the reason - or lack thereof - behind the decision isn't all that important. I've signed the petition at and think anyone with any interest in VFP should, but I don't expect anything to come of it. I'd love to be wrong.

What frosts me the most about the whole thing is the absolute BS we've been fed about VFP not fitting into .NET. I've had several conversations with Microsoft folk about making VFP part of .NET and they would always come back with silly arguments about "how would you compile …" If there were any merit to those arguments then in reality what they were saying is that VFP is more capable than .NET and if so, what kind of a "business decision" is being made here?

Maybe I'm just being too harsh and those guys at Microsoft just aren't that sharp after all. Maybe even with all of their vast resources the folks at Microsoft just can't figure this stuff out, yet a tiny little company like can.

Ok, ranting aside, the truth is it would've been more difficult to make VFP a .NET language back in the 90's because .NET wasn't as capable then and Microsoft was hell bent against dynamic languages. But now? Microsoft is investing in creating versions of Python and Ruby for .NET and of course already has Jscript. If these dynamic languages can be developed for .NET, there's no reason VFP can't be ported to .NET. The new DLR (Dynamic Language Runtime) for .NET should make this relatively easy. The marketplace has made Microsoft take notice of dynamic languages and as a result, a VFP.NET would take considerably less effort than it would've in the 90s.

Now, ask yourself this, if Microsoft is making business decisions about VFP, don't you think there should be some logic applied across the board? Look at the VFP, Ruby and Python markets. Which market offers millions of lines of code, thousands of developers, hundreds of large customers and hundreds of vertical market applications? Now ask yourself, where's the business decision here?

Thursday, May 10, 2007

Cool Tree View Code

I know that it has been a while since we published a Blog entry but we have been very busy. Leilani is growing quickly and doing very well overall. As you can see below she is hoping that the Red Wings win the cup again this year.

The following segment of code is something that I wrote a while ago when implementing a tree view in a form I was working on. I wanted to try something new to detect if a node needed the plus sign, indicating children were available. I was tired of always seeing the plus and having it expand to nothing. At the same time, I didn't want to load the tree with all of the children at startup either. The following is what I came up with.

(SELECT TOP 1 CategoryID
FROM Category SubCategory
WHERE ParentID = Category.CategoryID) AS Child

This code grabs all parent nodes (ParentID IS NULL) and the first child to that parent. The second block of code is how I populate the tree. If the Child field IS NULL, there are no children. If the child field has a value, there is at least one. As you may be able to tell by the synax, this is SQL Server code. The good news is that this also work with VFP code.

This.oTree.Nodes.Add(,1, 'KEY_' + TRANSFORM(CategoryID), Name)

This.oTree.Nodes.Add('KEY_' + TRANSFORM(CategoryID), 4, 'CHILD_' + TRANSFORM(CategoryID), "D")