Re: VFP Objects for a beginner - help!

I think that's pretty common. I remember when I was first learning it, it
seemed very complicated. Even after I figured out how it worked, I still
couldn't understand why anyone would want to write code in such a convoluted
fashion. It wasn't until after I used it for a while that the advantages
started to appear. Now, they're not only apparent, but mandatory - I just
couldn't, or certainly wouldn't want to, get by using old-style code.

Once you learn OO, it's much, much easier to use. Trust us on this.



"JWB" <none@xxxxxxxx> wrote in message
news:p0t6g.95$WP5.40@xxxxxxxxxxxxxxxxxxxxxxxx
I think I'm getting it. Definitely will need to read up. To this point I
thought of OOP as a nice way to organize code but no real benefit as far as
speed to my application over optimized code. So I only learned enough to
use other objects when needed, and usually that code was obtained here! So
I'd guess I've used only a small fraction of VFP to accomplish a heck of a
lot. My "stuff" is all large external DB manipulation and reporting
(reporting via VFP functions that write and publish the html/java script on
the fly). Super fast and capabilities that far exceed anything Crystal
Reports could touch.

However, now I'm faced with a pending collaborate effort where the end
result may be a .Net wrapper calling VFP and c# using an underlying Oracle
DB. To accomplish I've got to get my "stuff" organized in such a manner
that it can be broken in to components that will eventually be called by
another app. Too much info probably huh??

Thanks again for the tips it was very useful info.

- Ben

"Cindy Winegarden" <cindy_winegarden@xxxxxxx> wrote in message
news:%23XCEdI7bGHA.380@xxxxxxxxxxxxxxxxxxxxxxx
Just to add, you would create a project that had the class library(s)
(either PRG or VCX) in it and compile it as a DLL rather than an EXE. The
VB guy would set a reference to the DLL in his project and then could
instantiate the class, set it's properties as appropriate, and call its
methods as appropriate. Note that code compiled as a DLL can not have
_any_ user interface. Think of it as something that is "invisible" so the
user can't see it to click a button or whatever. However, as Dan's
example shows, you can write to a log file which is a useful way to debug
and also pass information to an operator.

Also, think of the object's properties as variables and the methods as
functions or procedures. The "OOP" way to pass in variables is to set the
object's properties. The Custom class is designed for use as a base class
for things like this; however, developers often use Session or Line
because they use less resources.

oTalk = CreateObject("Talk")
oTalk.SayWhat = "Hello world"
oTalk.Talk()

Define Class Talk As Custom
SayWhat = ""
Procedure Talk
MessageBox(This.SayWhat)
EndProc
EndDefine

--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
cindy_winegarden@xxxxxxx www.cindywinegarden.com


"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:eEn4b56bGHA.4108@xxxxxxxxxxxxxxxxxxxxxxx
These are deceptively HUGE and complex questions. LOL

An "object" (which really only exists at runtime) is nothing but a blob
that
contains some data and some code. It may or may not do something useful.

Using your "Hello World" as an example, you'd start with a class
definition
that might look like this:...

.... I want to begin porting
some of these paramterized functions in to objects that I can use
from within this app but also distribute so that another guy who is a
VB .net programmer can drop in his app. ....






.

Loading