>I've got a form with a date field. This date field needs to be converted to an OLE Date, and I've got a nice little conversion program that does that, which I call as a function. However, as soon as I define a function within a form method and try to close the method I get the following message:
>
>"Methods and Events cannot contain nested procedures or class definitions."
>
>So, I made another method with my conversion function...but then I also found that I have a leapyear function within the conversion function....and before adding another method to the form, I began thinking, maybe this isn't a "best practice".
>
>So, what are my options?
>
>1. I can place the function as .prg file in my source folder for the project
>or
>2. I can define new methods for the form, till the cows come home.
>
>or ???
>

Procedure files are still supported; you can put common UDFs into them and have them searched by SET PROCEDURE TO ... ADDITIVE. I use this to include common UDFs and to define non-visual classes - you can look at CLSHEAP to see examples of using a procedure file to do both things. I have wrappers on various API calls, common data validation and formatting UDFs and the like sitting in procedures as well. As long as you are willing to give up the use of relative object references like THIS, THISFORM etc in your UDFs, using procedures is still permitted.