LA Fox Presidents Column

The LA Fox Developer Newsletter

From the Pen of Ken (Con't from page 4)

envolved with form designer enhancements anyway. Between controlling the .SCX metadata and controlling the code generated, every single feature that currently exists will not only be compatible in 3.0, but will be much more WYSIWYG along with being more integrated with FoxPro 3.0’s built in event model. GENSCRNX is a tool that helps automate work done in the screen builder and in many cased breaks barriers that the native GENSCRN can’t support. If any tricks are used with native GENSCRN to obtain the specs for a FP 2.5 application, I guarantee that there will be much more development work in properly converting from 2.5 to 3.0 to take advantage of the new event model extensions. Most of these advanced functions created with native GENSCRN are implemented by placing code in the proper place in snippets. With GENSCRNX, most extended functionality is achieved through directives stored in metadata. A utility can easily convert directives in the Comment snippet to proper translations into specific event snippets supported by FP 3.0. Try creating a program that converts your .PRG snippets and UDFs into the proper events, It probably won’t be possible.

Here are some examples. How is a transporter in FP 3.0 going to handle hand-done 3D objects from a screen (shadows, lines). To achieve those 3D effects, every shadow effect is a separate object which is stored in a record and will certainly be mapped to FP 3.0 as it’s own record. You will have to hand delete *every* 3D object followed by manually changing the original objects settings to match the previous effect. With the 3D driver for GENSCRNX, a transporter utility will translate the

*:3D <options> directive into the new metadata that directly represents that effect (or creates new metadata to match it 100%). This will all me automatic, transparent, and probably take a few milliseconds to process. This is only one example, but the concept can be taken in relation to DragDrop and also built in GENSCRNX functions. What will happen when you transport a screen with special 3D objects in the .SCX over to FoxPro 3.0? You’ll have to delete them all and then manually change the 3D option for each object to reflect the previous look. With directives, the proper metadata can be created on the fly to fully auto-

XPro User Group News (Con? from page 1)

the Borland Workbench product to get an idea of the interface. “dBW will be compatible with previous versions.” This also appears to be true, though there will be some new additions and some well known Xbase constructs will become obsolete in the name of OOPs. Since Borland submitted some of the new syntax to the Xbase Standards Committee, making it public knowledge, I can point out one example. © SAY/GET will become obsolete (though still functional) in favor of a new object oriented language construct called TEXT. It will look something like TEXT <object name> AT <n,n cordinates> TO <n,n cordinates> <methods>. If you think about how OOPs works, this construct is much more syntactically orthoganal (look that one up!), whereas @ SAY/GET makes a rather cryptic (difficult to read) object.

In the course of some private email discussions about the future of FoxPro, the follwoing messages were sent to and from me to a will-remain-unnamed FoxPro. The name was changed to “John” to protect the innocent.

Fm: Randy Unruh To: John Doe John,

>>>Maybe I’m beginning to look prohphetic?<<<

>>Ya, but it’s SQL Server, not FoxServer<< Ah, but is it going to be “transparent”? That’s really the key for MSFT to keep Fox users/developers from jumping ship. After all, if an Xbase developer has to learn another language (and cryptic function calls) other than Xbase to make what Borland calls “upsizing” happen, it leaves the door open for that person to consider the product they primarily use for databased application development. I watched it happen in the Clipper community when Nantucket went from S’87 to 5.0. Many Clipperheads became Foxholes (Moi included), encouraged by marketing and communication mistakes Nantucket made.

With the ever increasing need for WAN throughput and client/server integrity driving Fox developers to look for solutions it just seems so misguided that MSFT would spend so much time and energy on Access while leaving FoxPro the dregs of their marketing effort. I entirely agree with you that 3.0 will answer many needs of FoxPro developers. But, encouraging FoxPro developers to move away from FoxPro to Access or Visual Basic in the interim leaves the door open for other non-MSFT products to be considered.