The LA Fox Developer Newsletter

May 1994

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

envolved with form designer enhancements any-

way. Between controlling the .SCX metadata and

controlling the code generated, every single fea-

ture 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 func-

tions created with native GENSCRN are imple-

mented 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 snip-

pets 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-

(Con't, page 6)

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 market-

ing 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.

(Con't, page 6)

Page 5