>I'm surprised that you want strict typing. I've programmed in C, C++ and I really felt that it was just a pain in the butt. VFP becoming strict type, it loses the charm of the xBase languages. But O.k. I agree to disagree.

Isn't that familiar?
LOCAL MyVar
MVar = .T.
...
IF MyVar
*-- Will not execute due to a syntax error in the assignment
ENDIF

I will gladly accept a Option Explicit type like in VB.

>I learned the OOP pricipals at universaty, But the assign and access was new to mee when I looked at Visual Objects For Clipper. Seeing how my colleage abused this feature to write programs, I began to dislike this feature, overall it can be simulated real easy, (as for the static memvar variable).

In the OOP books that I've read, it was mentionned many times that in a completly OOP environment, you should not access directly the properties of a class, but call a method that will return/assign the value. The guys from MS cut the apples in 2 for VFP. They let us talk directly to the properties, but we can manipulates the calls in the background.

You can do real cool thing with the Access and Assign method, like adding a new property on the fly if it doesn't exist.

>It's not a bug. It's a design error. The access and asign methods (I admit I haven't checked this througely) only fires on xbase code, not on internal C++ code. Can you describe a situation where you definitely want to use the assign and access methods ??

Having been burn myself with these methods, I must admit that you have to be carefull were you use it.

I allready gave an example above. Another one would be to store a value different from what the application see. Let say that you have a field called Colors. You could store this field in a integer format in the table. But you will need to remember in your programs that 1 mean "Red". With the Assign and Access methods, you could store 1 to the table in the Assign method if the calling program assign "Red" to the property and return "Red" in the Access method.

>Version 7.0 is pretty good. Though you can align controls with tabs on the rulerbar and have a align to grid feature, it misses features found on the aligning toolbar of VFP. Though this is irritating at first, there are lots of features that are far more user-friendly than the VFP report writer (changing lay-out in the preview mode).
>
>to name a few others:
>- changing the zoom mode from 25 - 400% (programmable)
>- Programmaticly assign a printerdestination to the report to print.
>- Easy programmable way to change paperformat and destination.
>- Use of subreports into one report (Multi detail band feature).
>- You can place the preview in any window you like.
>- Export to numerous formats, including Word, Excel, HTML and RTF.
>- Find text in the preview.
>
>Isn't this what we wanted in VFP for years ?
>
>Of course there is alway's something to complain about, but overall CR 7.0 is a far better report writer than the native VFP one.
>
>Once you've written your classes to intergrate CR into VFP it's almost as easy as calling a VFP report.

I admit that CR is better than VFP report writer for some reports and other reports are completly imposible in VFP. But for simple reports, I will use VFP report writer over CR, because it's simplier to use and need less files to distribute.