VFP Rookie Mistakes

x= CREATEOBJECT(“KeyCustomer”)   && hard-coded direct

y= oFactory.Create(“KeyCustomer”)  && delegation, parameter is just a locator.

• Drive creation and configuration from metadata.
• Hook the creation process.
• Possibility of centralized error handling.
• Endless other dynamic possibilities.
  

One thing you have to watch out for is the data session your object is created in when using a factory. This is especially problematic if the object is going to need to read data from a VFP cursor. Of course you could design your factory to switch its current data session to a passed in session id prior to creation. Another possiblity is to use the factory to provide the concrete class name based on the token hence code like...

x = CREATEOBJECT( oFactory.GetClassName("KeyCustomer") )

Yup, good point. In those circumstances you could always say:

oTempFactory = CREATEOBJECT("Factory")
x= oTempFactory.Create(“KeyCustomer”)

(Perhaps an additional possible rookie mistake would be creating objects in the wrong data session.)

If you are planning to use remote views then upsizing is not as painful because you can map the date type in the view even though its datetime type in the database. The only caveat is that we allow datetime fields to be nullable in the database and because we are binding to field classes we translate this in our value_access/value_assign accordingly. (actually, the VFE framework does this for us. If you need to do SPT (which we still do for OLAP and reporting operations) then you need to be aware of the datetime and null issues. As for the logicals, bit fields in SQL work nicely and natively map to VFP logicals, even in SPT (except in the where clause you still need 0/1). However, I know that Oracle did not have this type the last time I checked. Not sure about the My SQL and other backends -- Randy Jean
I agree about bit fields in SQL Server. But in my case, I worked on a project writing a vertical market app to support either VFP, SQL Server, or Oracle backends. One of the technical goals was to have as little variation as possible between choice of backends. I learned some lessons about common data types, reserved words, etc across those three backends. Also as stated above, I agree that it's worth the trouble to allow nulls in your VFP data if you think you're headed towards a SQL backend. -- Guy Pardoe

WITH THIS.grdDtlLines
   LOCAL laControlSources[.ColumnCount],lnColumn
   FOR lnColumn=1 TO .COLUMNCOUNT
      laControlSources[lnColumn]=.COLUMNS(lnColumn).CONTROLSOURCE
      .COLUMNS(lnColumn).CONTROLSOURCE=[]
   ENDFOR
ENDWITH
.
< do the refresh data stuff >
.
WITH THIS.grdDtlLines
   FOR lnColumn=1 TO .COLUMNCOUNT
      .COLUMNS(lnColumn).CONTROLSOURCE=laControlSources[lnColumn]
   ENDFOR
ENDWITH

Actually, there are still a lot of people who run 640 x 480 even on 17" monitors. They simply can't read text on the screen at higher resolutions--and this includes many people who don't have "official" visual impairments, but whose eyes are just going through middle-age-related changes. ALWAYS ensure that your application can run in 640 x 480, and if you have the ability, eschew the use of operating systems that don't support 640 x 480. -- Ken Dibble

Remember that "640x480" is the whole screen, you might only have 640x400 available for a form. The Windows status bar, the VFP title bar and a menu all make the screen shorter. -- Geoff Franklin

We had the reverse problem, forms designed to work at 640x480 but too small for users with new 14" 1440x1080 laptops.

It would be even better to design your applications with accessibility in mind (font choices, colors, etc.). Couple that with some resize code (or use anchors in VFP9) and you're on your way. -- Tod Mckenna

      IF !USED('sometable')
          USE sometable IN 0
      ENDIF
      ... do some work
      USE IN sometable
      

      LOCAL lopened
      IF !USED('sometable')
          lopened = .t.
          USE sometable IN 0
      ENDIF
      ... do some work
      IF lopened
          USE IN sometable
      ENDIF
      

      LOCAL lopened
      IF !USED('sometable')
          lopened = .t.
          USE sometable IN 0 AGAIN ALIAS SomeTable
      ENDIF
      ... do some work
      IF lopened
          USE IN sometable
      ENDIF
      

1. What records to update
   • 0 (only the current record)
   • 1 (all pending records and fail the update completely if any record fails)
   • 2 (all pending records and if any record fails continue with the rest and put the record numbers that failed in the array specified in the 4th argument)
2. Force past update conflict (.T. will overwrite the changes of other users .F. will fail the update if another user has made changes
3. The alias in which the update should occur
4. The name of an array to store the record numbers that failed to update when first argument's value is 2

*OR* (another viewpoint)

Just put the following in the Macro, and use code in the the program to do the cleanup:

{CTRL+F2}{CTRL+END}DO X:\PATH\CLEANUP{ENTER}

  obj = create("theAncestor")
  obj.foo("hello")

  define class myBaseclass as Custom
    procedure foo
      lparameters param1, param2
      if pcount() < 2
        param2 = "World"
      endif
      ? param1 + " " + param2
    endproc

  enddefine

  define class theAncestor as myBaseclass
    procedure foo
      lparameters param1, param2
      ? "I said:"
      ***dodefault(param1, param2) && pcount() in myBaseclass::foo PCOUNT() will always be 2!
      DO CASE
      CASE PCOUNT() = 1
          dodefault(param1)
      CASE PCOUNT() = 2
         dodefault(param1, param2)
      OTHERWISE
         dodefault()
      ENDCASE
   endproc
  enddefine

LPARAMETERS m.tcParm1, m.tcParm2
*Here's a subclass' overridden method.
LOCAL m.lcParmList
m.lcParmList = PassParms("m.tcParm1, m.tcParm2",PCOUNT())
RETURN DODEFAULT(&lcParmlist.)

*PassParms.PRG
LPARAMETERS m.tcParmlist,m.tnItems
RETURN LEFT(m.tcParmlist+",",AT(",",m.tcParmlist,m.tnItems)-1)

* main.prg
do menu mymenu
do form myform
READ EVENTS
* cleanup code here
return   && or quit