4

The LA Fox Developer Newsletter
April 1994
FoxPro 3.0 Preview
by Bill Anderson

Toward the end of the Microsoft DevCast of March 30, a preview of FoxPro 3.0 was shown. Those in attendence did not sign an NDA, so the viewers can discuss what was shown. To my knowledge, the FoxPro 3.0 has not even gone into alpha; anything seen here could change or be discarded before the rollout of the product. Neverthless, the few minutes showing the “sneak preview” gave an indication of the direction of the next FoxPro.

Chris Capposella did the demonstration. The first thing I noticed as Chris was speaking was the toolbar across the top the screen. This is consistent with other Microsoft products. Chris was talking about object orientation coming to FoxPro as well as User Defined Classes. Chris followed this by typing this line in the command window: x = create object(’tazform’). He indicated that the properties of each object and the screen itself could be changed at runtime. Grid control as well as change to grid control was also mentioned.

Then Chris typed x.show at the command window; the form appeared. Chris stated that multiple instances of the same screen could be run. He went back to the command window, (with the screen x still up and running!) typed yx and y.show; there were now two forms on the screen. Back at the command window he typed y.caption = ‘DevCast 4’ and it appeared in the title bar of the second screen.

Chris then said he would demonstrate inheritance by adding a double click event. He got rid of the two screens and went back into the code for one of the screens. Under the PROCEDURE dblclick he added some code (I don’t remember the details), ran the screen and demonstrated that the double click event was now being trapped. A few more words were spoken, but that’s all that was shown.

If the above is any indication of what is to come, FoxPro is going to change a lot. I would recommend preparing for another steep learning curve. A good start would be to learn the basic fundamentals of object oriented programming. Also, put
aside a fair amout of time to learn the product when it comes to market I don’t expect it to be all that difficult once we get the hang of it, but we may have a lot of procedural programming to “unlearn”. Not that current techniques won’t work, but they may be superseded by other syntax that is superior to the current model. Let me warn you though, the above opinions were surmised after only a five minute demonstration and should be judged accordingly.

Some messages on the Compuserve FoxUser Forum noticed some details that I missed. For instance, the command window was visible throughout the demonstration. That in and of itself means nothing. But in the context of creating multiple instances of a screen and being able to go back and forth between the screens indicates the event handling was part of the screen behavior. In other words, it didn’t have to be coded. In other words, no READ DEACTIVATE, READ VALID, etc. necessary!

One thing I did notice throughout the 4 hours was a consistent tendency of the Microsoft presenters to mislabel some programming terms. For example, a presenter would say that a block of code was “reusable” and proceed to cut and paste it elsewhere. Another presenter opened up a program file and proceeded to “drill down” which involved using the scroll bar. But I didn’t catch the misuse regarding the FoxPro 3.0 demonstration.

After Chris Capposella displayed the two screens and changed a title in one, he spoke of “inheriting” a double click event. He proceeded to go into the code, put some code into the PROCEDURE dblclick and reran the screen. Wrong! If that were true, all FoxPro programmers today know “inheritance” and it would be known as changing a procedure. Were Chris to truly show inheritance, he would have created a new class from the previous class and add a double click procedure.

To recap, this was a pretty packed five minute demonstration. And by reading between the lines, one can get a fairly good sense as to the direction of FoxPro
3.0.

My thanks go to Ken Levy for his technical assista on this article.

[Ed. Note: See also Ken Levy’s article on Page 9]
Page 4

4