VFPConversion Blog

This blog is dedicate to the adoption of technologies such as Microsoft .NET or SQL Server in addition to Visual FoxPro. Expect posts on this blog to be fairly technical, as this blog is geared towards developers, testers, and technical decision makers.

Content Area Footer

Thursday, April 06, 2006
Europe's first set of VFPConversion Workshops

We just went through our first set of European VFPConversion Workshops in Germany and Austria. We were not really sure what to expect, since some people especially in Germany were relatively set on using VFP in the future. To our surprise and delight, we received a warm welcome there, and people were genuinely happy with the workshops we delivered. We may be tooting our own horn here, but we received the following feedback (translated), so we think people liked what they saw:

The first day had tons of info, especially about OOP concepts that are strange to VFP developers such as interfaces, delegates, and so forth. Everyone I talked to found these topics to be very interesting. Some a little confusing perhaps, but interesting nevertheless. It was clear that some concepts would take a while to sink in.
Also, the second day, which was very practice-oriented entirely fulfilled expectations.

I have not met anyone who thought that it wasn't worth attending.
Most were motivated to see more.
Everyone was happy with the competence and entertainment value of all the speakers.

In the german newsgroups, someone posted the following message:

When I went home after the workshop yesterday, my head was about to explode. :-)  I would like to say thanks to everyone involved in organizing the workshop (ProLib and EPS). The event was very well organized.
The content was top! The only thing that would have been better is for the workshop to last 2 weeks instead of 2 days ;-)

We received the following message via email:

I would like to thank everyone for a very well done workshop in Kassel! After the workshop I had the opportunity to talk to some colleges. All of them seem to agree that "this isn't as bad as I thought!" and "starting in 2007, I want to do all my new development exclusively with DotNet.".

I have to agree. I feel the same way. I will continue to use VFP and VFX, which saves a lot work (not just due to the builders). But for new things, especially if it involves a web interface, and if the data is to be stored in SQL Server or Oracle, I will use Visual Studio.

And as a side-remark: Why are we VFP developers so negative about data access in .NET? If I use VFP with Views and CAs and my data is stored in SQL Server, then I am facing practically the same scenario [as in .NET].

Also per email:

I would like to thank you for a very informative and professional workshop in Kassel!

"Should I develop in .NET?". As a die-hard VFP developer, I have never even asked myself this question before. After all, there isn't anything better than Visual FoxPro ;-). But after attending this workshop, I am convinced! My conclusion: To use up-to-date technologies in the future, one has to use .NET. For this reason, it is important to start using .NET sooner rather than later. And as far as I am concerned, it is "5 minutes to twelve" and I want to start right away, before it is too late. In fact, I would even appreciate an additional, in-depth workshop as a followup event.

So it seems people liked the events. It of course is always good to get such feedback! We are now also thinking about doing more workshops in Europe (one for Zurich, Switzerland is already planned) and of course also in North America (Montreal is next in combination with DevTeach). We are also thinking about more advanced workshops (more than 2 days each). If you think that is a good idea, send us some feedback! And of course, you always have the option of calling us in for a personalized training session or other VFPConversion related services. For more information, check our In particular, the training and events page.

Posted @ 9:37 PM by Egger, Markus ( -

Tuesday, March 07, 2006
The next VFPConversion events...

A series of VFPConversion events is coming up shortly. The next 2 events are in Europe (Germany and Austria and - a bit later - in Switzerland). A few seats are still available, although especially the German event is filling up quickly. For more information, check out the German event site.

There will also be events in North America. The first one is held together with DevTeach 2006 in Montreal. Click here for more information on that event.

Also, if you would like to see an event in your area, send us an email ( 


Posted @ 8:58 PM by Egger, Markus ( -

Monday, March 06, 2006
Good Luck, Ken!

Longtime VFP icon and guru, Ken Levy, has left his position as VFP Program Manager, and is moving on to the Microsoft Windows Live team, where he is going to build a developer community.

This move has been originally announced in the February 2006 VFP newsletter, and Ken has now started his new position. We wish him the best of luck!

Ken himself has blogged about his move. You can read about it here. He will certainly be missed in the VFP community, but I would be surprised if he wouldn't pop up here and there and continue to be VFP's unofficial embassador...

Posted @ 8:15 PM by Egger, Markus ( -

Monday, February 06, 2006
Disaster Recovery

Does disaster recovery matter to you? Well, it should!

Check out my recent post on the new "Manager's Blog", for more...

Posted @ 8:55 PM by Egger, Markus ( -

Thursday, January 05, 2006
The Display Resolutions Dilema

A few days ago, I posted a message about display resolutions, font smoothing, screen sizes, and related issues on my general development blog. It seems that issues like display resolution are rather simple, yet there is a lot of complexity hidden here. Us Fox developers know a bit about that, since in the past we had to move from FoxPro DOS to FoxPro Windows via "Foxels" rather than pixels.

However, there is a lot more to know about screen resolutions, which is why I ultimately ended up posting a article-size message about how screen resolution is measured, why standardized resolution measuring is completely broken in Windows today, why it is hard to read lots of text on the screen, and how to build applications that are both resolution independent and very crisp due do much higher resolutions than applications can achieve today.

In short: Anything we look at should be at a resolution of at least 300dpi. Ideally even 600dpi or 1200dpi. Today, we are nowhere near that (generally 96dpi). This is a major problem for many industries, and current generation Windows apps that are based on GDI, can not break through this massive roadblock. This is one of the major reasons why practically nobody reads a book on the computer and why so many people like to print out reports. "Avalon" (or the "Windows Presentation Foundation", I should say) aims to provide a solution. In fact, providing a solution to this very problem is one of the major purposes of Avalon.

So anyway, check out my post. Some of the pixels, points, dpi, and resolution measurements may not be what you think they are. I think there might be a few details even advanced developers are not aware of...


Posted @ 7:19 PM by Egger, Markus ( -

Saturday, December 10, 2005
Visual FoxPro 9, Service Pack 1 Released

Microsoft has just released Service Pack 1 for Visual FoxPro 9. It can be downloaded from the VFP web site on msdn.

This service pack focuses on bug fixes. For more details, see Ken Levy's "Letter from the Editor" for December.

Posted @ 1:36 PM by Egger, Markus ( -
Comments (1)

Tuesday, December 06, 2005
New Language Features in C# 3.0

C# has been a fascinating and vibrantly alive new programming language. Each version of C# has introduced exciting new language features, such as Anonymous Methods and Generics in the 2.0 version (note: Generics ultimately ended up in the CLR and are available in other languages as well). C# 2.0 has just been released, but what few realize is that .NET languages usually are far ahead of the Visual Studio release they are usually released with. C# 2.0 for instance has long been completed, but it has taken Microsoft some time to build .NET Framework and Visual Studio features around those new language features.

This means that the next version of C# (which will have the version number 3.0) is already available in limited form (mainly for people who attended PDC). There once again is a fascinating list of new features available in that version, such as Type Inference, Object Initializers, Anonymous Types, Lambda Expressions, Expression Trees, and the 500 pound gorilla of new features: LINQ.

A new online article of mine focusing on most of these features (I just touch on LINQ... everything else is present) has just been made available to CoDe Magazine email newsletter subscribers, and it is also available online. Another online-only article explicitly focusing on LINQ will also be made available soon (and a more in-depth one will follow in the printed magazine). I will also publish an article about new language features in the next version of Visual Basic soon.

Even if you never intend to use C# 3.0, there are a number of interesting things in C# 3.0 that are significant (or at least interesting) for any developer using an object-oriented language.

To get this eColumn, it is best to sign up for our email newsletters. You can do so at:

You can also see this article online at this URL:

Posted @ 7:48 AM by Egger, Markus ( -

Sunday, November 27, 2005
Custom Types in .NET

I recently discussed an interesting problem with a customer that I thought was worth sharing here. This particular customer has a system that (among many other things) measures things. Such as the length (or dimensions) of a wooden bar. While this in itself is a pretty trivial problem, things get pretty tricky, because the system handles both metric (meters, centimeters,...) and imperial (feet, inches,...) values, and this is a problem that is much harder to solve than it seems on the surface. Things get tricky because this is not just a mathematical problem, but also a business problem. Here's why: Sometimes, conversions need to be exact. If you need to put glass into an opening that is 10 foot wide and thus turn it into a window, then you will need to tell your European partner to cut it to a width of 304.8cm exactly, or else it will not fit or leave a whole. On the other hand, if you are partaking in an international construction project and plan to cut pieces out of a 10-foot bar, then you will be hard-pressed to find a shop that sells you a 304.8cm bar. Instead, you need to order a 3m bar (it is also rather annoying to go through an entire construction project calling something a "304 centimeter and 8 millimeter bar" instead of a "3 meter bar"). So depending on the situation, conversions need to be done quite differently.

The system currently is written in VFP, and it is a bit of a headache to handle all these different measurements entered in different systems. Every time someone deals with any measurement, one has to fully understand all the details involved and how to handle all the values. Consider a simple example where something that is 5 feet in length needs to be added to something that is 2 meters in length. First, the developer has to determine both values. Then, the developer has to figure out what systems both values are in. The developer also needs to know whether the result is desired in imperial or metric form. The other value then has to be converted based on a set of rules (exact or estimated conversion), and finally, the result as well as information about whether it is in imperial or metric has to be stored in memory or in the database. And of course, this has to be done in every single instance that has anything to do with measurements. Needless to say that in a system that is mainly concerned with keeping track of this stuff, there are many such places. And of course the chances of getting it wrong every now and then are pretty high too.

Another area that is problematic is the UI for all this. What values would we bind the UI controls to? If we have a list of values, how can we easily sum them up (in a report perhaps)? It really is a much more complex scenario than one would think at first.

What could we do in VFP to ease the pain? Well, we could provide objects with methods that take away the implementation complexity. Conversion methods would be useful. The ability to parse a string such as "5m 6cm 13mm" might be useful. Perhaps a method that can convert between two systems in a rounded manner would be nice ("10 feet" is about "3 meters"). Maybe some sort of notification system that allows us to handle an overall system switch from imperial to metric so all the forms know which system to display data in. These types of features would certainly ease the implementation pain. However, they do little to simplify the overall problem. All these methods and objects still need to be invoked whenever one deals with those values. Sure, it gets easier to do the right thing, but the burden of figuring out what the right thing is is still up to the developer.

The .NET Solution

The .NET solution we proposed goes a completely different way that is not available in VFP. It is thus also not entirely obvious to VFP developers (at least initially). So bear with me for a moment...

In .NET, there really is no difference between types and classes. In VFP, things are different. The system provides a number of default data types that are used to store information, and classes are a bit of a different animal altogether. In .NET on the other hand, there is no difference between a String data type, and a custom class or object. The solution to this problem therefore is the creation of a custom data type (which is the same as creating a new class).

Of course, this data type is a bit different in nature from a simple number or string, but this is really not that unusual in .NET. Consider the Guid type. While we normally think of a Guid type as a long sequence of numbers, it really is a combination of multiple individual values that are handled as a single type. The representation of a typical Guid (such as "e319123f-522f-4c05-8aed-f095a5eac253") is really just the string representation of the relatively complex data a Guid maintains internally. Another example for a more complex data type would be a point or vector in 3D space, which is really a combination of 3 different values. On the other hand, it is really just a single atomic data unit.

This is quite a different way of thinking about data than we find it in VFP. In VFP, if we were to store the coordinates of a point in 3D space, we would use 3 numbers. And everyone who used that piece of information would have to know how to handle those three numbers. For instance, if there were 2 separate points in 3D space, and we wanted to calculate where they are relative to each other, then we would have to know how to handle the 6 individual numbers. Quite the nightmare really, and very error-prone. In .NET on the other hand, we would simply have two pieces of data each representing a point, and we could handle them without any knowledge of how to handle 3D coordinates. For instance, we could simply subtract those two coordinates and get their relative positions.

3D coordinates are not something the typical business application developer needs very often. Handling units that could be imperial or metric on the other hand is a more "normal" scenario. And the same basic ideas can be applied here. So how would such a data type work exactly? Well, let's assume we created our new type (class) and called it "Length". I envision that we could then use our Length like so:

Length length1 = new Length("5 foot 6 inch");
Length length2 = new Length("1m 25cm");
Console.WriteLine("Total length: " + (length1 + length2).ToString());
Console.WriteLine("Total length (imperial): " + (length1 + length2).ToImperial().ToString());
Console.WriteLine("Total length: " + (length1 + length2).ToMetric().ToString());
Console.WriteLine("Imperial to Metric: " + length1.ToMetric());
Console.WriteLine(length1.System);  // Prints "Imperial"
Console.WriteLine(length1.Value);   // Prints "5 foot 6 inch"
Console.WriteLine(length2.System);  // Prints "Metric"
Console.WriteLine(length2.Value);   // Prints "1m 25cm"

The exact syntax could be slightly different of course and is completely up to our implementation. The key here is that this new data type is completely self contained and integrated into the overall system. It can simply be instantiated and used. Two lengths can be added or subtracted from each other, and all the logic needed to make this happen is contained inside the type. Developers using this type do not have to worry about how to add two values no matter what system they are in. (Operator overloading allows for operations such as length1 + length2).

The type could also have properties that provide access to values in different systems. There can even be an overall switch for the display value by adding a static property (which is shared across all instances of the type), which sets the default for display values:

Length.DisplaySystem = Units.Imperial;
Console.WriteLine(length1.Value);         // Prints "5 foot 6 inch"
Console.WriteLine(length1.DisplayValue);  // Prints "5 foot 6 inch"
Console.WriteLine(length1.RoundedValue);  // Prints "5 foot 6 inch"
Length.DisplaySystem = Units.Metric;
Console.WriteLine(length1.Value);         // Prints "5 foot 6 inch"
Console.WriteLine(length1.DisplayValue);  // Prints "1m 67cm 64mm"
Console.WriteLine(length1.RoundedValue);  // Prints something like "1m 65cm (est!)"

Creating such a custom type allows us to keep all the logic that goes with length calculations in the business layer where it belongs. UI controls simply bind to this new data type. In fact, the UI has no concept of this type being different from a standard type such as a string or a decimal.

The remaining question is how to store this information. Our new type stores more than one piece of information (at the very least, it would store the value and the system). In a database such as SQL Server 2000, the internal values need to be split into their individual parts and stored in separate fields. In SQL Server 2005 on the other hand, the custom type can also be defined in SQL Server and thus be stored as an atomic (single) unit of data.

Of course, a single blog post can not cover the details of how the implementation of all of this works (this post is already rather lengthy). Perhaps this is a good topic for a future paper. However, there already are a few other papers that provide information about some of the involved core concepts:


Posted @ 5:29 PM by Egger, Markus ( -
Comments (11)

Tuesday, November 15, 2005
EPS Is Hiring...

EPS is hiring! For various positions, actually, but the most pressing opening we are trying to fill is the one described here:


The EPS Custom Software Group provides leading edge software solutions and services for Enterprise clients worldwide. We employ world-class talent who continuously research, evaluate and use best of breed methodologies, tools and techniques. Our guiding principle is obsessive dedication to flawlessly accomplishing assignments, working at the highest level while keeping them on time and on budget. The EPS Custom Software Group strives to provide its clients with custom solutions that precisely fit their current needs while retaining the flexibility to grow as business needs change.

EPS Software Corp ( is currently accepting resumes for a senior level Requirements Analyst. The position is located in Northwest Houston (Spring), Texas. In this position, you will work directly with clients to determine business logic and produce application requirements. You will also create application design and work closely with the development team defining and monitoring work priorities and scheduling throughout the project lifecycle.

  • Experience working directly with clients to produce high level Requirements Documents
  • Experience explaining to clients the project technical issues in language that the client understands
  • Experience interacting directly with Software Developer teams to produce low level, detailed Use Cases and System Functional Requirements, including UI designs, UML diagrams and data models
  • Technical and programming background with Microsoft technologies that include C#, VB .NET, ASP.NET and SQL Server including a strong understanding of object oriented, n-tier systems architecture relating to Windows, Web and database applications
  • Experience in the software development lifecycle using RUP as well as Agile application development methodologies
  • Experience using software tools (e.g. Excel, Word, Project and Visio) to develop project and system documentation


  • Five or more years of experience in business process analysis and software development
  • Broad knowledge of business practices and operations
  • A four-year college degree in Computer Science, Management Information Systems or a related field
  • Expert written and verbal communication and documentation skills.
  • Highly organized and able to effectively communicate ideas through conversation and documentation
  • Strong interpersonal skills and the ability to lead and motivate project teams and to grow relationships with customers
  • Ability to assimilate information from a variety of sources into a form that is targeted to the client/customer as well as to the software development team
  • Ability and experience working on multiple tasks and projects simultaneously and demonstrate abilities to establish work priorities and schedules
  • Possesses meeting facilitation skills
  • Emotional maturity to deal with stressful situations
  • Any equivalent combination of education, experience and training that provides the required knowledge, skills, and abilities

If you are interested, contact us at

Posted @ 5:04 PM by Egger, Markus ( -

Monday, November 14, 2005
Markus' Avalon (WPF) Examples from DevConnections

My Avalon (Windows Presentation Foundation) examples from the recent DevConnections show are now available online.

Here's the link to my blog posting with the examples:

The Windows Presentation Foundation (formerly known as "Avalon") is the WinFX-generation user interface technology that replaces current Windows UI. (Think of WinFX as ".NET Framework 3.0"). This technology is entirely based on the Managed Platform (".NET") and thus only available for .NET developers.

Posted @ 1:59 PM by Egger, Markus ( -

Monday, October 31, 2005
Markus on .NET Rocks!

Last Thursday, the .NET Rocks Internet Radio Talk Show stopped by in Houston as part of their road trip (see I went to the user group meeting, and we gave away a bunch of CoDe Magazines. As you may know, we have a partnership with .NET Rocks. For instance, we have a dedicated page in the magazine where we usually print excerpts from their show. Carl and Richard are also giving away magazines at every location, even though we are not a true road trip sponsor. At the end of the show, they take a bunch of people into their road trip RV ("the boat") and interview them. I also gave a short interview, discussing CoDe Magazine and also our Milos Solution Platform effort.

Check out the interview at Also check out some of the other recordings from other road trip locations.

Posted @ 8:30 PM by Egger, Markus ( -
Comments (1)

Monday, October 31, 2005
Visual Studio 2005 and SQL Server 2005 Released

Visual Studio 2005 and SQL Server 2005 are now available for MSDN subscribers on MSDN Online. The official release date isn't until November 7th, but MSDN subscribers already get the final bits.

Releases of both products have been eagerly anticipated as another round of great new features can be found in them. Also, these are very important releases, because many of the upcoming technologies (such as WinFX and LINQ) are based on the .NET Framework 2.0.

Posted @ 8:28 PM by Egger, Markus ( -

Tuesday, September 27, 2005
My (Markus) Interview on The Fox Show

Here is something that almost fell through the cracks of hurricane Rita:

Last week I gave an interview to The Fox Show (click here for a link to my individual episode). Looks like I went overboard again. :-) The whole thing is almost an hour long, which means I keep my record in terms of getting the longest shows when I give interviews (the same happened on .NET Rocks!).

The interview mainly focuses on using VFP and .NET together, and why that is important (or at least figuring out whether it matters for one personally, or not). I also talk a bit about CoDe Magazine, the Milos Solution Platform, and communities. I thought it was a fun interview to do, and I think there is lots of stuff there for VFP and .NET developers alike.

Posted @ 2:05 PM by Egger, Markus (EPS Software Corp.) ( -

Sunday, September 25, 2005
All Systems Back Up and Operational

We just managed to completely restart all our servers and are back to what should be normal operating mode. The power situation may still be a bit shakey and we could experience additional outages, but most likely, we should be OK.

Really, not all that much happened where we are, even though we were pretty close to the storm. For those interested in the details, check out this blog.

Posted @ 10:49 AM by Egger, Markus (EPS Software Corp.) ( -

Thursday, September 22, 2005
Hurricane Rita Downtime

EPS and CoDe Magazine offices will be closed for the rest of the week due to Hurricane Rita. Most likely, our servers will be down for the next few days, so none of our sites will be operational, and we will most likely not have any email access either.

Posted @ 2:14 AM by Egger, Markus (EPS Software Corp.) ( -
Comments (5)

Tuesday, September 20, 2005
PDC 05 - A Recap

PDC rocked this year. A lot of new technologies were shown, and many of them are important for all modern developers, including VFP people. Here's a quick recap:

From an EPS and CoDe Magazine point of view, we had a great conference. We were a media sponsor, had a double-sized booth, and a lot of traffic and excitement going. Our magazines were in all the attendee bags, so we were able to do other things at the booth. We gave away tons of bags that ended up showing up everywhere (we even saw a few at the LAX airport a few days later). We also had temporary CoDe Magazine tattoos. If you were spotted wearing one, you were eligible to win cool prices, such as a PSP. People loved this one, and we had a lot more people with tattoos than we expected. Some in places we hadn't expected either. ;-)

So long story short: We probably had more than our share of exposure at PDC. Kudos to the CoDe staff, in particular Tammy, Cleo, and Tom, who came up with all the great ideas. (And also thanks to Tammy's mother who helped out at the booth!)

As far as PDC in general is concerned, I was also rather pleased. There seemed to be a lot of excitement around new technologies. Here are some that I thought were cool:

  1. Windows Vista. No need to say more.
  2. Avalon (excuse me: Windows Presentation Foundation): The Northface demo at the keynote rocked. Some of the other examples (like the photo album) were pretty cool too. There were tons of session on WPF, and many of them were very valuable. VFP does not support Avalon natively of course, but Avalon UIs can still access VFP components through COM interop.
  3. Windows Communication Foundation (formerly "Indigo"): Lots of great sessions on this too. Indigo is basically a new generation of web services (simplified said). Indigo replaces a lot of technology like Web Services, DCOM, Remoting, MSMQ, and a lot more. It can of course interact with all these technologies, but the real power of Indigo comes to light when both sides of the connection use Indigo (as would be the case in a distributed application). VFP of course can interop with Indigo through web services and DCOM protocols. I am still hoping for a tigher integration though. But considering that it is all based on managed code (".NET code"), it is probably a bit far fetched to expect that.
  4. Windows Workflow Foundation: This was a new announcement at PDC. Pretty nifty. Workflow built into .NET/WinFX on a framework level. I have not yet had a chance to look into how and if this can be used from VFP.
  5. Microsoft Expression: One of the highlights in my book. MS Expression is a suite of new design tools, including a new drawing program that is a mixture of pixel and vector based drawing. (Currently code-named "Acrylic"). Then, there is an Avalon/XAML designer called "Sparkle". This is a pretty cool piece, especially if you are into advanced UI design. And there even is a new web designer called "Quartz". So lots of new stuff here for both win and web developers. Check it out at Of course, all of this is a .NET exclusive...
  6. LINQ (Language Integrated Query): The second major announcement at PDC05. C# and VB.NET will have query features integrated right in the language similar to how it workes in Visual FoxPro (except LINQ is a lot more powerful). This allows the developer to use SELECT-style query operations on data sources as well as pretty much anything else, such as XML and collections of objects or arrays. You want to select data from a database that is joined with controls on a form and data coming from XML and return a collection of business objects? No problem with LINQ! Unfortunately, this stuff will not release before Orcas (the next version of VS after 2005), but you can already get early bits! We will provide some in-depth info on this in the upcoming 2 issues of CoDe Magazine (first to the punch again ;-) ). You can also expect a lot of information about LINQ on the site.
  7. Atlas: ASP.NET controls that use the new AJAX paradigm (which turns HTML-based interfaces into a richer experience). Pretty cool as well! (And once again a .NET exclusive...)
  8. SideShow: Aux Displays are now called SideShow. This is still a very very cool feature.
  9. Office 12: Quite radically different from an interaction (UI) point of view. No more menus and no more toolbars. Looks pretty neat, but I haven't had a chance to play with it myself. Can't wait to start using it though...

And there was a lot more. So there will be a lot of stuff to talk about for CoDe Magazine and also on this blog! There are a lot of very cool technologies on the horizon. At this point, practically all of these technologies are based on the Managed Platform (".NET"), and the few occasions where this is not the case one needs to use C++. But of course, we see it as our very purpose to make sure VFP developers get the information and tools needed to use these technologies as well.

So stay tuned...

Posted @ 10:26 PM by Egger, Markus (EPS Software Corp.) ( -
Comments (2)

Monday, September 12, 2005
Off to PDC

This year's main event is finally upon us: PDC (MS' Professional Developer Conference) in L.A. In fact, I would even consider this to be the main event of the last 2 years, since PDC is not an annual event. This is one of the few conferences I really am still looking forward to.

CoDe Magazine is a Silver Media Sponsor, so we should be fairly visible at the show. If you want to talk to me/us or our authors and editors, stop by at our booth (#516)!

See you in L.A.!

Posted @ 3:52 PM by Egger, Markus (EPS Software Corp.) ( -
Comments (9)

Saturday, September 10, 2005
Southwest Fox: The New Number 1 in US Fox Conferences?

The (Visual) FoxPro DevCon has had quite a turbulent history, from the humble beginnings in Toledo (Fox Software), to the "official" Microsoft FoxPro DevCon, to a joint operation between Tech Conferences and Advisor, to DevCon the way it is today, hosted by Advisor in Las Vegas.

DevCon is still a valuable event, but compared to previous years, it has changed drastically. The value in terms of content is still there, but the community part (by many considered at least as valuable) is all but gone. At the most recent DevCon, hardly anyone from the old "Fox Gang" was even there. Bummer!

Also, many other events that covered FoxPro in the past are no more. Whil Hentzen's Great Lakes Great Database Workshop is no more. FoxTech Toronto is no more. And even for Advisor's DevCon, no announcements have been made about when and where future events will be help (which is highly unusual for Advisor, and makes me wonder...). Only DevTeach Montreal (a conference we are heavily involved with) has a significant amount of VFP content. Beyond that, one has to go to Europe or South America to find FoxPro events (such as the dFPUG conference in Germany, or the Czech DevCon in Prague...).

But there is a new event that seems to be taking the spot of the "can't miss conference": Southwest Fox!

There seems to be a lot of excitement about this conference. The community seems to have adopted this conference as "their" event, and there are many great speakers. And while I am not sure what Microsoft's official take is on the conference situation, I am getting the impression that they have taken a liking to this conference as well. So as far as I can tell, this is going to be the event to be at for people interested in VFP conferences. Plus, the cost is real reasonable too!

So will we be there? Yes. We are still working on details though, but Rick Strahl will be there for sure (in fact, he is even hosting a separate event for West Wind users). Rod Paddock is scheduled to be there as well. Personally, I have a conflict, but I am hoping to work that out as well, so I think there is a good chance I might go too! I sure wouldn't mind hanging out with the Fox Gang again...

Posted @ 11:39 AM by Egger, Markus ( -
Comments (6)

Wednesday, September 07, 2005
More About Interfaces: A Specific Example

One of our customers who currently is in the process of moving his development efforts from VFP to .NET recently sent me a very good question about interfaces. I get similar questions a lot and they seem to be very typical for VFP developers who are moving to .NET (not surprisingly). So I decided to put some of it on this blog:


I read your article in Foxpro Advisor May 2004 about interfaces and polymorphism, but I'm still a bit puzzled by your philosophy in Milos about the use of interfaces. I see that you might want a virtual method to have parameters whose types are interfaces rather than (abstract) classes---so that other classes that do not derive from the given abstract class may use the method. But I'm not clear on why your have so many methods and properties return values that are interfaces. For example,

Why does BusinessEntity.GetBusinessObject() return generic type IBusinessObject instead of class BusinessObject? Why is the property BusinessEntity.AssociatedBusinessObject of type IBusinessObject instead of BusinessObject? Why does EntitySubItemCollection.GetItemObject() return generic type IEntitySubItemCollectionItem instead of the specific class? Similarly, why do Add(), GetItemByIndex(), ParentEntity and this[int] have return types that are interfaces, not classes?

Theoretically, I suppose the answer is the same: so that these methods and properties may be used with classes that do not inherit from the provided or usual parent class. I guess I'm just having trouble imaging situations where this would be useful.

Also, I'm wondering if it would be advisable to add overloads of the these methods and properties in my application-specific subclasses that return object of application-specific classes. For example, is it OK to have an overload of CorporateUnitBusinessEntity.GetBusinessObject() that returns a CorporateUnitBusinessObject? Or would you advise just using the interfaces?

If you have time, could you explain this a little more, or refer me to other articles about it? Thanks.

Note: This customer is using our Milos Solution Platform. The particular objects and classes he refers to are all Milos components. However, everything discussed here applies for all .NET development.

Here's the answer I sent:

Basically, the interface defines the contract. It says "this is what we want a business object to be like, and we shall now refer to it as IBusinessObject". From that point forward we really do not care what someone does to comply to this contract as long as they do.

Now of course, we would not want everyone to implement their own business objects from scratch, so we provide the default implementation in the form of the BusinessObject class. This makes it very easy to conform to the standard.

You could also conform to the same standard by using a different class that implements the same interface. For instance, we are about to provide an EnterpriseBusinessObject class which works better with Enterprise Services. That object has to be subclassed from a special class in the .NET framework. Had we not provided an interface, then this would not be possible, because we would have to inherit from BusinessObject. But since we could not inherit from BusinessObject and the enterprise class from the .NET framework, this would not work.

Similarly, it could be that someone you want to sell your app to already has other infrastructure in place that does data access and other things our business objects do. If you want to use that person's object in your app, then all you have to do is add an implementation of IBusinessObject, and you are done. But if the interface was not available, then you'd have to change the inheritance structure of the other person's class, which (if possible at all) would have almost certainly broke that object.

So using an interface provides an extreme level of freedom, reusability, and integration. In addition, providing the default classes provides great simplicity. We have a general rule that for everything we do, we first create an interface and then create a default class that implements that interface.

And as an answer to the following part of the question...

"Is it OK to have an overload of CorporateUnitBusinessEntity.GetBusinessObject() that returns a CorporateUnitBusinessObject? Or would you advise just using the interfaces?"

...I sent this:

Yes, absolutely. You do not even really have to worry about this. GetBusinessObject() always expects an object of type IBusinessObject as the return type (you can only override that method. Overloads can only be created by different parameters... return types are not considered for overloads, since an app can completely ignore return types).

Anyway: You do not really have to worry about the particular type in this case. Consider this example:

public override IBusinessObject GetBusinessObject()
    return new CorporateUnitBusinessObject();

Now while this looks like we are returning the type CorporateUnitBusinessObject, we really are returning IBusinessObject, because since CorporateUnitBusinessObject inherits from BusinessObject we automatically have an object that implements IBusinessObject (since BusinessObject implements IBusinessObject). So in fact, this object IS of type/interface IBusinessObject (and then some... but that is ignored here and all the methods that call this method do not care about the extras anyway).

So in essence, the above example is exactly identical to this:

public override IBusinessObject GetBusinessObject()
    CorporateUnitBusinessObject obj = new CorporateUnitBusinessObject();
    IBusinessObject ref2 = (IBusinessObject)obj;
    return ref2;

This is where the strongly-typed nature of .NET really kicks in. Since we wanted to creat a generic way for all business entities to get a handle to the associated business object so tasks such as saving can be handled automatically. Of course, in a strongly typed language, we had to specify a type, but what was that type going to be? BusinessObject? In that case we would have given up a lot of flexibility since we would have entirely relied on inheritance, which is a somewhat limited technique, since a class can only inherit from one other class. Should we have typed it to be CorporateUnitBusinessObject? Obviously not an option, since we had no clue someone was going to create that object. Should we have used type "Object"? That would have nullified strong typing and all the benefits and quality improvements that come along with it. So using the interface really makes generic programming like this possible in .NET and at the same time allows holding on to all the quality gains.

For all VFP developers, this is a very unusual thing to do though, because we just never had the concept of interfaces in a meaningful manner. I always find it very easy to explain the fundamental concept of interfaces, but once it comes to the implications (this is only one example), then only real-world implementations do the trick.

Interfaces are very interesting. They are so foreign to VFP developers, yet they are so helpful in creating flexible and powerful application architectures. Interfaces are easy to explain but the consequences are hard to comprehend until all of a sudden, one day you will say "heck... now I got it! How could I have ever done without interfaces?". Maybe this message will help you to get a little closer to that point (unless you already reached it...).

Posted @ 3:21 PM by Egger, Markus ( -
Comments (7)

Tuesday, August 30, 2005
Sign Up for Free Issues of CoDe Focus Magazine!

Every so often, we produce special issues of CoDe Magazine that focus in on a specific topic. We call these special issues CoDe Focus Magazines.

These magazines are distributed at special events such as conferences or product launches. We generally distribute them free of charge to our subscribers and additional mailing lists. If you are interested in receiving such free magazines, click the link below. (Regardless if you are a current subscriber or not! Everyone qualifies for a free issue!)

Click here to be added to the list!

There are several issues planned at this point. One that will ship fairly soon targets Tablet PC and Mobile PC Development. There is also a very good chance that we will produce another Visual FoxPro Focus issue. The link above will allow you to sign up for those issues and also for issues beyond that. This will give us a good idea of what topics we should be tackling first and how much interest there is in VFP content. So make sure you tell us about as many of your interests as possible.

Feel free to pass this on to your friends...

Posted @ 7:17 PM by Egger, Markus ( -
Comments (2)

More Posts: Newer Posts - Older Posts








Syndication RSS 2.0 RSS 2.0

All My Blogs:
My personal blogs:
Dev and Publishing Dev and Publishing
Travel and Internat. Living Travel and Internat. Living
Other blogs I contribute to:
Milos Blog (US) Milos Blog (US)
VFPConv. Dev Blog (US) VFPConv. Dev Blog (US)
VFPConv. Dev Blog (DE) VFPConv. Dev Blog (DE)


Blog Archives
All Blog Posts

    February (1)
    November (1)
    October (2)
    April (1)
    March (1)
    August (1)
    July (1)
    June (2)
    March (1)
    January (1)
    December (1)
    November (2)
    October (1)
    September (1)
    August (1)
    April (3)
    March (2)
    February (1)
    January (1)
    December (2)
    November (3)
    October (2)
    September (7)
    August (3)
    July (4)
    June (12)




This Blog is powered by MilosTM Collaboration Components.