Wednesday, July 20, 2005
Some Interesting Stats...
Microsoft recently posted some interesting stats about VFP developers.
One interesting set of data looks at the current
group of VFP developers and what other products they use:
- 20% of VFP developers also use VB6, 13% VB.NET, 12%
use C#, 10% use Java, and 8% use C++
- 26% of VFP developers also use VS.NET, 21% ASP.NET
So at least about a quarter of VFP developers (not counting people who have moved off to .NET)
are also using .NET in some form. This means that close to three quarters of the
current VFP community has not yet adopted .NET. However, a lot of them are
generally interested in .NET, as the following stat shows:
- 31% of current VFP developers who have not looked into .NET yet are
planning to do so within the next 2 years
Or on other words: About 40% of the remaining three quarters plan to adopt .NET
in the next 2 years. This will bring us to a total of 57% (or more) of current VFP
developers using .NET within 2 years. This is very interesting, because it means
that counting the people who used VFP 12 months ago but have now moved to .NET
(which are not included in the above numbers), the majority of VFP
developers will adopt .NET. (Well, even not counting those that have
already moved, this statement is still true).
What is also interesting (and cool) is that 98% of the current VFP developers
(and this also includes EPS!) predict that they will still use VFP 12 months
from now in some capacity (for EPS, this probably applies much longer).
VFP developers also seem very open minded when it comes to databases:
- 55% use SQL Server
- 22% use MSDE (the "small version of SQL Server")
- 21% use MySQL (the "open source equivalent to SQL
- 14% use Oracle
- 4% use DB2
One could interpret this as "almost all VFP developers use a non-VFP
database". However, while there seems to be some truth to that (most large
apps certainly seem to be using a dedicated database server product these days),
a full 89% still use DBF files, at least in addition to other databases (if not
At EPS and VFPConversion.com, we think these are pretty amazing and
encouraging numbers. Adopting technologies like .NET and SQL Server in
combination with Visual FoxPro certainly makes for a very powerful
Posted @ 10:25 PM by Egger, Markus (email@example.com) -
Monday, July 18, 2005
Exposing strongly-typed VFP COM objects to .NET
VFP is a weakly-typed language by nature,
and that can cause problems when consuming VFP objects from .NET through COM
Interop. One way to improve the developer’s experience on the .NET side is by
adding type information in the VFP code to make the VFP object a "little more
strongly typed" (even though VFP still won’t enforce type-safety internally,
allowing developers to do things like assigning logical values to string
properties from within VFP ). Here are some things one can do to make exposed
elements more usable in .NET:
- Specify the type of method parameters,
as well the type of the return value
- Make use of the COM_Attrib array in
order to provide information that gets generated in the object's type-library
describing properties exposed by the object.
- Create well-defined interfaces that
describe what’s exposed by other objects that are used by the COM object.
For instance, consider the simple Employee
Define Class Employee As Biz Of Biz.prg
Iemployeedata In "DataObjectInterfaces.EmployeeData"
*-- Keeps a Reference To the Data Object.
oData = Null
*-- Properties For Error handling
lError = .F.
cErrorMsg = ""
employeePK) As Boolean
whatever Code populates the oData Member.
AddProperty(This.oData, "EmployeeID", 99)
AddProperty(This.oData, "EmployeeName", "Jane Doe")
Iemployeedata_get_EmployeeID() As Number;
Iemployeedata_put_EmployeeID(eValue As Number @);
This.oData.EmployeeID = eValue
Iemployeedata_get_EmployeeName() As String;
Iemployeedata_put_EmployeeName(eValue As String @);
This.oData.EmployeeName = eValue
*-- Property's attributes for COM
lError_COMATTRIB = COMATTRIB_READONLY
lError_COMATTRIB = "Indicates
whether an error has occurred inside the object."
lError_COMATTRIB = "lError"
cErrorMsg_COMATTRIB = COMATTRIB_READONLY
cErrorMsg_COMATTRIB = "Info
about last error."
cErrorMsg_COMATTRIB = "cErrorMsg"
oData_COMATTRIB = .F.
oData_COMATTRIB = "Keeps
master data object."
oData_COMATTRIB = "oData"
oData_COMATTRIB = "IDispatch"
- The GetEmployeeByPK method defined one parameter of type string, and the
return type is a Boolean (logical value in VFP).
- COM Attrib arrays are created for public properties, specifying more
information about each one of them (that information is used when the
type-library for the COM object is created).
- The class exposes an oData member, which is created on the fly. In order
to expose that in a strongly-typed manner, the class implements an
IEmployeeData interface (listed below), which in turn determines what members
are exposed by the oData object.
The IEmployeeData interface is created off of the following class:
// Declare variable and create business object.
EmployeeClass oBiz = new
// Call method to retrieve
// Get a reference to the business object as a data
Iemployeedata oData = oBiz as Iemployeedata;
// If we got the reference properly, we can start using the
if (oData !=
this.txtEmployeeID.Text = oData.EmployeeID;
this.txtEmployeeName.Text = oData.EmployeeName;
An article about this will soon be posted to the www.vfpconversion.com
Posted @ 12:19 PM by Lassala, Claudio (firstname.lastname@example.org) -
Monday, July 11, 2005
Why Interfaces Are Important
.NET supports the concept of interfaces in addition to classes. So does VFP.
However, in VFP interfaces are only required in special scenarios, while in
.NET, they are used all the time. This is something VFP developers need to get
But why is that exactly? There are a number of reasons why interfaces are
incredibly important and useful. This post represents just one example scenario.
Before we look at that, we need to address the question "what exactly is an
interface". An interface is the definition of methods and properties and object
has. In VFP, when we create an object, it just ends up with all the methods and
properties define (which is also true in .NET). With a specific interface
definition however, it is possible to set the expectations. This is very
important for code reuse and generic programming.
Let's examine a simple VFP example: Let's say I want to create a toolbar that
has a save button. Whenever that save button gets clicked, it will call the
Save() method on the active form. This means that I expect that the form has a
Save() method. In other words: I expect that the form "implements an interface
that has the Save() method". In VFP, I can call the Save() method in the
In VFP, we do not have to specify that the active form implements a certain
interface. If a form has a Save() method, it will get called. This makes things
very easy, but it also has a significant downside: If the currently active form
does not happen to have a Save() method (perhaps because the developer forgot to
add it), then the system will crash during runtime. There is no way for the
compiler to verify whether or not the ActiveForm object indeed has a
.NET's strong typing solves this problem. In .NET, object references always
are of a specific type (or class... which is really the same as a type in .NET).
So let's say we have a reference to the active form called "ActiveForm". (For
now, we do not care how that came to be). This reference would not just be typed
as an object (as in VFP), but it would be of type "System.Windows.Forms.Form".
In VB.NET, we could define this like so:
Dim ActiveForm As
ActiveForm.Save() ' Fails!!!
However, the "Form" class does not have a Save() method. Therefore, the
compiler would not let us get away with defining a reference as "Form" and call
a Save() method. Instead, we would have to create a special form class that does
have a Save() method:
Public Class SaveForm
Public Function Save() As
' Save and return success code in subclasses
Now, we can use this form to define the type of our variable, and are thus
able to call the Save() method on it, since the compiler can verify that every
object reference that can be stored in this variable must have a Save()
Dim ActiveForm As
So far so good. The problem with this is that inheritance is a very static
technique. Just like in VFP, we can only subclass any class from one parent
class in .NET. And in this scenario, that means we already maxed out our
options. So if we have some cool class that we wanted to use as the parent
class, then we can't, because we always need to inherit from "SaveForm". Once
again, in VFP that is not a problem, because we could just add a Save() method
to our new form. But then again, that would lead to a quality problem that we
really wouldn't be happy with in modern development. And that's where Interfaces
come into play!
Interfaces allow us to define that a certain object has certain methods,
without wasting an inheritance relationship. So instead of creating a class, we
can define an interface:
We can now create a form class that subclasses from whatever other form class
we want it to subclass, and in addition, we always implement the interface we
Public Class MyCoolForm
Function Save() As
' Save here...
When we now talk to an object created from this class, we can look at it in
several different ways: We can look at it as a generic form (without a Save()
method), or we can look at it as type "MyCoolForm" (which has a Save() method,
but our toolbar button would not know that since it has no concept of what
"MyCoolForm" is), or as type "ISaveForm" (which has only a Save() method and the
toolbar button can use it). So we can do this:
Dim ActiveForm As
ISaveForm ' Uses the
Works, no matter what it is subclassed from
The nice thing is that this is all very easy to do (once you get comfortable
with this new concept), and it is very easy to quality control, since the
compiler can verify 100%, that our code will work at runtime.
Posted @ 2:07 PM by Egger, Markus (email@example.com) -
Friday, July 01, 2005
Care to Enumerate?
Have you checked out .NET enums yet? No? Well, you should!
Enums are a handy way to define a limited list of setting. Let's say you have
an object that stores different types of phone numbers. How do you define the
types? Perhaps you have a PhoneType property, which might be a numeric
type. 1 stands for office phone, 2 for home phone, 3 for cell phone, and so
forth. The problem with this approach is that it is hard to memorize all these
settings. As a result, it is easy to get the mixed up, or assign a value that is
invalid altogether. In .NET, there is a very simply solution to that particular
problem: You define an "Enum". This can be done like so:
Office = 1,
Cell = 3
This defines a new type/object (remember that there is no difference in .NET
between a data type and an object) which derrives from the .NET internal type
"Enum". This is the fancy way of saying "we created something that is an object
and it behaves according to the rules of enums". This means, we can now use this
enum in our code:
This defines a local variable called "myType", and it is of type
"PhoneTypes". This would be kind of like the following statement in VFP
(assuming this was available in VFP, which it isn't):
LOCAL myType AS PhoneTypes
We can of course also assign a value to our variable:
myType = PhoneTypes.Cell;
What's cool is that we do not have to remember that a 3 indicates a cell
phone. We just say "PhoneTypes.Cell" as we defined it in the enum. Also, we do
not even have to remember which PhoneTypes are available, because as soon as we
type "PhoneTypes." C# IntelliSense provides a list of all available PhoneTypes.
(Note: If you do this in VB.NET, the editor works even better by showing the
list of available phone types as soon as you type the "=" sign...). Note also,
that we have to pick one of the available options, if we pick something else,
then the compiler catches the problem and won't let us get away with it.
(Although there are some "expert tricks" to cheating that system, but we will
ignore those for now...).
Of course, we can also expose properties that take advantage of this new
wherever the value comes
wherever we want to store the value to = value;
What's also very cool is that it is very easy to store the actual numeric
value to the database (or retrieve it from there). Let's say phoneRow
is an ADO.NET DataRow out of a DataTable in a
DataSet, and "iType" is an integer field in the underlying SQL Server
table. In this case, our property could be coded like this:
In other words: We can simply cast any enum to an integer value, and
vice-versa. If our database field has the integer value 2, and we cast it to our
enum, it will end up as "PhoneTypes.Home". Pretty slick,
Posted @ 10:49 PM by Egger, Markus (firstname.lastname@example.org) -