The LA Fox Developer Newsletter

August 1997

VFUG’s Hot Tips

[Ed. Note: Last month, we featured several hot tips from

Fox Talk, one of several publications designed to further en-

hance our world. This month, we continue that trend by featur-

ing several hot tips from VFUG, an online Visual FoxPro

Developer Newsletter. For information on how to become a

member and receive their newsletter, e-mail Scot Becker,

Dire ctor of Marketing and Public Relations, Virtual FoxPro User

Group (VFUG), scot©vfug.org. Or visit their website at http://

www.vfug.org.]

Below are some of the VFUG’s latest tips, tricks, and FAQ’s.

These are so fresh, they may not even be loaded into the FAQ

section by the time you read this!

Determining Affected Rows

by Sundar Raman

Ever wondered exactly how many rows were affected by that

update statement that you sent to your SQL SERVER data-

base? I ran into the problem when attempting to determine

whether the change that I requested was actually committed by

my request, or possibly by another user. Checking for the

changes after the update with a select statement is not appli-

cable since the change may have been committed by a different

user on the network (concurrency queues). The solution that I

finally found to work is to use the ROWCOUNT value that SQL

Server seems to store for the connection:

cSQLString = “update tablename set fieldi = ?someval, field2 =

?someotherval where fieldi = ?oldval”

iRetVal = sqlexec(hnd, cSQLSTring)

if iRetVal c 0 then

*

a connection level error happened, and is reported by the

odbc error handler endif iRetVal = sqlexec(hnd, “select

@@rowcount”,

"csrTemp") if iRetVal <0 then

*

a connection level error occurred

end if

select csrTemp

cField = field(1)

cRowsAffected = csrTemp.&cField

NOTE: No query can be executed on the current connection

between the update request, and the rowcount request. The

buffer gets cleared by SQL Server every time a query is ex-

ecuted, and this includes things like SQLCOMM ITO, and

SQLROLLBACKO.

Copying Structures

by Sundar Raman

It is very convenient to create classes to hold structures that

need to be passed around a program, to different procedures

and functions. The classes are always passed by reference.

Every so often, it is useful to create a copy of a structure,

maintaining most of the element values, but to be able to

change some of the element values temporarily. Foxpro,

unfortunately, does not allow you to create a new instance of a

class by direct assignment. Direct assignment creates a new

pointer to the same space, or a rew reference to the same data:

obji = createobject(”myclass”)

objl.propl = “poopi”

obji .prop2 = “poop2”

objl.prop3 = “poop3”

* trying to create a new instance, so we don’t have to explicitly

copy

* all the properties over

obj2 = obji

&& this creates a new REFERENCE to the

original object obj2.propl = “poopA” && this changes BOTH

obj2.propl AND objl.propl

&& of course we could always perform explicit

&& assignments, but who has the time for that?

obj2 = createobject(”myclass”)

obj2.prop2 = objl.prop2

To simplify this process, I wrote the following -

&& Example class definition and code

otest = createobject(”testclass”)

otesti = 0

otest.cloneobject(~otest1)

define class testclass as custombaseclass

propi =

prop2 =

prop3 =

enddefine

&& Custom base class that Includes the Cloning method:

define class CustomBaseClass as custom

procedure CloneObject

Iparameters toDest

local oTemp, aTemp

dimension aTemp(1)

?this.class

oTemp = createobject(this.class)

=amembers(aTemp, this)

if alen(aTemp) = 0 then

return

endif

for i = I to alen(aTemp)

if !sys(1269, this, aTemp(i], 1) then

*

property is read-write, so we can

set

the value

oTemp.&atemp[i] = this.&atemp[i]

endif

endfor

toDest = oTemp

release oTemp

release aTemp

endproc

enddefine

Moving the Print Preview Into

Your Own MDI Form

by Arnon GaI-Oz

(* How to preview reports in your own forms (instead of the

Page 5