debug issue

[rdonnay]

thanks guys.. question: what's the problem with public variables?

What Tom said plus:

Publics are not a good option for modular applications. They make your code difficult to incorporate into a larger application.

You should NEVER use publics when trying to develop portable code that can be used in multiple applications, such as a Document System, Calendar System, etc.

Publics and Privates make code difficult to maintain because the programmer must have intimate knowledge of the entire application. It is very difficult to understand code in subroutines and functions that must access Public and Private variables because there is no pointer back to the origin of the variable. Locals and object-oriented code make it much easier to encapsulate code so that it becomes more portable.

I work a lot with code written by other programmers and nothing is more difficult to work with than code that uses Publics and Privates. Team programming is almost unmanageable, unless there are only a few.

Tom's comment about other threads stepping on Publics is not a really big issue for me because I found a solution to that problem many years ago. You can temporarily Privatize a Public variable when launching a new thread like below. I developed this technique when converting a large Clipper application that needed to run existing code in multiple windows.

Code: Select all

FUNCTION Main()

PUBLIC cCustomerName := 'Roger Donnay',  cCustomerPhone := '208-999-9999'

oThread := Thread():new()
oThread:start({||EditCustomer()})


FUNCTION EditCustomer()

PRIVATE cCustomerName := cCustomerName
PRIVATE cPhoneNumber := cPhoneNumber

cCustomerName := 'Tom Liehr'
cPhoneNumber := '+011 64 888 8888'

RETURN nil

[Wolfgang Ciriack]

Hi Roger,
i want to replace all my public vars with a object from VARGROUP, which is saved to a xpf file, so that i have only one public.
My problem is, if i add a new var to the object, and the saved object is restored from the xpf file at my customers side, how can i update the saved object with my new var ?

[rdonnay]

That is a good question. I will look into this.

[rdonnay]

I wrote a test program demonstrating that you can add or remove vars from a vargroup and still restore from a previous XPF file.

Compile and run the below code:

Code: Select all

#INCLUDE "dcdialog.CH"

FUNCTION Main()

PUBLIC oVars

DCVARGROUP TO M->oVars NAME MYVARS ;
   Date := Date(), ;
   Time := Time(), ;
   Job := 'Customer', ;
   Name := 'Steve', ;
   Zip := '12345', ;
   Array := {1,2,3,4,5,6}, ;
   Window := AppDeskTop()

SAVE ALL LIKE oVars TO VARS.XPF

DC_InspectObject(M->oVars)

ClassDestroy(M->oVars)

DCVARGROUP TO M->oVars NAME MYVARS ;
   Date := nil, ;
   Time := nil, ;
   Job := 'Invoice', ;
   Name := 'Larry', ;
   Zip := '56789', ;
   Array := {1,2,3,4,5,6,7,8}, ;
   Window := AppDeskTop(), ;
   Path := DC_Path(AppName(.t.)), ;
   Default := Set(_SET_DEFAULT)

RESTORE FROM VARS.XPF

DC_InspectObject(M->oVars)

ClassDestroy(M->oVars)

DCVARGROUP TO M->oVars NAME MYVARS ;
   Date := nil, ;
   Time := nil

RESTORE FROM VARS.XPF

DC_InspectObject(M->oVars)

ClassDestroy(M->oVars)

RETURN nil

* ---------------

PROC appsys
RETURN

[Wolfgang Ciriack]

Hi Roger,
thanks for your example. Am i right, that the DCVARGROUP from 255 is different from VARGROUP in 253 ?

[rdonnay]

Am i right, that the DCVARGROUP from 255 is different from VARGROUP in 253 ?

Yes, you are correct.
Build 255 supports both the old VARGROUP and the new DCVARGROUP.

The difference is that DCVARGROUP supports initialization of the variables in the command syntax.