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
Posted @ 2:05 PM by Egger, Markus (EPS Software Corp.) (email@example.com) -
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
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
Posted @ 10:49 AM by Egger, Markus (EPS Software Corp.) (firstname.lastname@example.org) -
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.) (email@example.com) -
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
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
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
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:
- Windows Vista. No need to say more.
- 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.
- 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.
- 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
- 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 www.Microsoft.com/Expression.
Of course, all of this is a .NET exclusive...
- 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 www.VFPConversion.com site.
- 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...)
- SideShow: Aux
Displays are now called SideShow. This is still a very very cool
- 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
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.) (firstname.lastname@example.org) -
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.) (email@example.com) -
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.
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
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 (firstname.lastname@example.org) -
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
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
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
"Is it OK to have an overload of
CorporateUnitBusinessEntity.GetBusinessObject() that returns a
CorporateUnitBusinessObject? Or would you advise just using the
...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
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
So in essence, the above example is exactly identical to
public override IBusinessObject
obj = new CorporateUnitBusinessObject();
IBusinessObject ref2 = (IBusinessObject)obj;
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 (email@example.com) -