Writting a Function

[twigs1981]

I'm new to foxpro and more accustomed to C/++ where I can just write a function anywhere I want so could someone please explain to me how to write a function i.e. seperate file, function declaration, returning(and is the type returned specified?), passing by value/reference. I don't have any books on VFP 6.0 and I'm at work :-/

thanx in advance

 

[GriffMG]

Twigs1981,

Hi, most projects in VFP contain at least one .prg file into which start-up code is generally added.

You can fill this with functions and procedures, after the basic start-up stuff.

Additionally, if you use a SET PROCEDURE TO statement to refer to another .prg file you can access the functions and procedure that you place in there.

There are limits to the number of functions and size of the .prg files - but in practise I have not exceeded them yet, 6500 lines is perfectly possible.

HTH



Regards

Griff
Keep [Smile]ing

 

[twigs1981]

great! well thats a good start! what does it look like syntaxicly to declare a function I'm so use to:

<return type> <funct name>(<args>)
{
[return]
}

and {} block statments aren't used (as far as I'm seen) in VFP so could you give me a generic funct please?

 

[GriffMG]

Hi Twigs,

The format can be broadly similar, here is one for handling a date:

FUNCTION ZDATE
	PARAMETERS m.DATE
	PRIVATE m.DATE, m.STRING
	M.STRING = ""
	IF !EMPTY(m.DATE)
		M.STRING = DTOC(m.DATE)
	ENDIF
	RETURN(m.STRING)

This probably isn't typical of most of my colleagues here, they would code the same thing:

FUNCTION ZDATE(m.date)
	Return iif(!EMPTY(m.DATE),DTOC(m.DATE),"")

Delcaring the variables in the function header makes them local implicitly (I think).

VFP is not so highly typed as C, or Pascal, so you don't have to specify the function return type - or the type of any parameter, they work like variants in VB.

Does this help?



Regards

Griff
Keep [Smile]ing

 

[EzLogic]

Func Multiply(Num1,Num2)
Local Ans
Ans = Num1 * Num2
Return Ans
EndFunc


Or

Func Multiply(Num1,Num2)

Return (Num1*Num2)
EndFunc

Or

Func DoSomthing()
Messagebox(&quot;I will do something here&quot
nAns = DoSomethingElse() && Calling Another function
EndFunc

Func DoSomethingElse()
Return &quot;Hello Dude&quot;
EndFunc

Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan

 

[GriffMG]

Something to note from the above VFP is pretty much case insensitive for variable, fields, function names etc - but string and character comparisions are generally case specific.

Martin

Regards

Griff
Keep [Smile]ing

 

[twigs1981]

thank you very much! time to work! well when lunch is done

 

[Mike Lewis]

Twigs,

Just to add to the good answers you've already seen:

In general, there are three places in VFP where you can write your function code:

- At the bottom of any &quot;open&quot; PRG file. By &quot;open&quot;, I mean one that has already been executed in the current session. You need to put all your function (and procedure and class) declarations) after the last line of the main code.

- In a dedicated PRG file, that is, a file that contains nothing but function or procedure declarations. You can have as many of these as you like. You must &quot;open&quot; them by executing a SET PROCEDURE command some time before you call the first function.

- In its own PRG file, that is, a PRG which contains just a single function declaration. In that case, you don't need the FUNCTION header, provided the filename is the same as the function name.

Hope that's not too confusing. It'll all slot into place soon enough.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[Mike Gagnon]

MikeLewis

In general, there are three places in VFP where you can write your function code:

What about Custom classes and function right into objects or controls, memo fields, COM objects, DLLs, FLLs ?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Mike Lewis]

Mike,

What about Custom classes and function right into objects or controls, memo fields, COM objects, DLLs, FLLs ?

Hmm. I'm not sure if I would agree with objects, controls or COM objects. We were talking about functions, not methods. As for DLLs, I don't think you can write a Foxpro function in a DLL -- as opposed to calling a function from a DLL.

On the other hand, maybe we should add stored procedures to the list.

Mike



Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[wgcs]

You can build DLL's in VFP, then use those DLL's in other VFP programs...

Also, many people who learned Java before learning VFP will have no difference in their mind between functions and Methods: In Java, to have a library of functions, you have to make them methods of a class (though, as &quot;Static&quot; methods, you can call them without instantiating an object of that class...). As a result of this, I've seen many people recommend doing the same thing in VFP... Though, personally I don't see any benefit to this over using &quot;normal&quot; procedures and Functions. (Note: I'm not talking about things that &quot;belong&quot; in classes... I'm talking about utility functions that require no &quot;context&quot; when they're executing.

 

[GriffMG]

Haven't we all drifted a bit, the question was how do I write a function?

Pretty easy:

Function MyFunction(MyParam1,MyParam2)
  ** do something
  return(MyParam1+MyParam2)
EndFunc

Personally I don't use the EndFunc, because I generally only program one exit from any function. But that's just me, others will differ.




Regards

Griff
Keep [Smile]ing

 

[Mike Gagnon]

MikeLewis

As for DLLs, I don't think you can write a Foxpro function in a DLL

Maybe it is time to establish what the difference between a function, procedure and a method. The only difference I understand is that normally a function returns nothing a procedure does, I'm not sure about a method but I think in the end they all blend into each other. BTW you can create a VFP DLL that will return a result. I'm currently work on a DLL (or more precisely an FLL) that all VFP and returns all kinds of system values. (Like Focus.fll)

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[GriffMG]

Mike,

The whole purpose of a function is to return something, isn't it?

A procedure has no return value. I'm not 100% use about a method, or an event - 'valid' returns .t., .f. or a numeric.

Could we all live with the idea of all these things is to provide a process, which might return a value, or alter the value(s) passed to it, or perhaps alter the contents of global values, or even alter someting else.

Hmmm. My argument is pretty weak - forget it!




Regards

Griff
Keep [Smile]ing

 

[Mike Gagnon]

Griff
You are correct, I mixed them up, here is what someone smatter then me wrote
&quot;Functions VS Procedures

Functions can return a value.
Procedures do not return such a value
When a function or procedure changes its environment its makes a side effects


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[GriffMG]

That's what I was trying to say...

But I'm not worthy Mike!

Thank you...

Regards

Griff
Keep [Smile]ing

 

[wgcs]

However, in VFP this is completely valid:

DO doSomething with Date()
if doSomething( Date() )
  wait window "Something"
endif

PROCEDURE doSomething( pdDate )
  if dow(pdDate)=1
     RETURN .T.
  else
     RETURN .F.
  endif
ENDPROC

So, you CAN return values from a Procedure in VFP.

The only real difference in VFP between a function and a procedure is... the word used to define it (and the (unnecessary) matching ENDxxxx word to end it).

Both functions and procedures (in VFP) can be called 'like' functions and 'like' procedures... that is:
like a function: var = function( param, param2 )
like a procedure: do Procedure with param, param2
If you don't set a return value in a procedure (that is, if the procedure ends with &quot;RETURN&quot; instead of &quot;RETURN SomeValue&quot;, or &quot;ENDPROC&quot; with no RETURN at all), then the default return value is .T.

Now, the difference between the two calling mechanisms are that SET UDFPARMS TO Reference|Value only affects how parameters are passed to functions... Procedures ALWAYS have parameters passed by... well, I can't remember: Either always by Reference or by value... anyway, SET UDFPARMS doesn't affect it.

HOWEVER, SET UDFPARMS can be overridden with parentheses:

SET UDFPARMS TO REFERENCE
xx = DoSomething( param1 )   && Passes implicitly by ref.
xx = DoSomething( (param1) ) && Passes explicitly by value
xx = DoSomething( @param1 )  && passes explicitly by ref.

SET UDFPARMS TO VALUE
xx = DoSomething( Param1 )   && passes implicitly by value
xx = DoSomething( (param1) ) && Passes explicitly by value
xx = DoSomething( @param1 )  && passes explicitly by ref.

So, in VFP, there IS NO difference between Procedures and Functions... same with Methods of an object: They are ALWAYS called as Functions, (ie, you can't: DO MyObject.SomeMethod WITH param1, param2)
And you don't have to return a value from a method, but the default return value will be .T. if you don't specifically &quot;RETURN SomeValue&quot;

 

[Mike Lewis]

Yes, I agree that we have drifted a bit off the original question. Maybe that doesn't matter -- it's an interesting discussion.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[wgcs]

I don't think we've drifted too far off the topic: This discussion has thoroughly answered the original question, and it is interesting... exploring different approaches to procedure libraries, etc...