<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
'm a strong opponent to that position. I think UDFs, functions that have a broad application across
several places still should be kept as functions. We still have str() and substr() functions, we don't
have to use object method calling like _vfp.substr(). So no I wouldn't wholesale move a proc lib into
object methods. I also don't have "A" huge proc file anymore. Each of my UDFs lives in it's own
.prg, with the .prg name the same as the function so what I use in each app, is just what that app
needs. I see UDFs as language extentions, and methods as the required intelligence of an object
to carry out it's purpose.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

David,

I am 900% in agreement with you on this one. I have seen far too many
classes that could have been done as functions, with the result of an
unnecessary application payload. Everything you say on this issue I agree
as it is my thinking too which is why we have 200 or so individual UDFs.

The Form Manager I wrote is a CUSTOM class, not a FORM class. It needs
to be as a class as, unlike with Functions, it needs to keep track of
property variables and arrays - if I used functions I would need a
system of Public variables instead. So, it is because it is a CUSTOME
based class that I was thinking of transferring all its methods and
properties to a CONTAINER class so that I could then visually refer
to it whenever needed.

Michel.


==================== Original message follows ==================

>Michel,
>
>>Am I interpreting this correctly : I wrote a form class which fires up all
>>my forms, keeps track of them, hides them, releases them, etc... It works, however the problem I have found with it is that it is a PRG which I keep
>>keep in a procedure file, along with other custom classes, and there is no
>>VISUAL way of me to look up the class's methods, properties, etc... Each time
>>I have to open up the PRG and scroll through the doc or code to work them
>>out, or print it.
>
>If your form manager is derived from Form there is no reason at all that it can't be worked on in the Class Designer. The only class I have in a .prg is my hdrSeeker class that my searchable grids use. Header, Column, Page, OptionButton can not be visually subclassed. You can CREATE CLASS FormManager as Form and copy/paste your existing .prg code into the methods.
>
>>If I understand it correctly, the beauty of what you describe is that
>>I could implement my Form Manager class through a container where each of the
>>class's methods are methods of the container. This way, any time I want to
>>look up what methods or properties are available, I can do it visually
>>and much more quickly and efficiently through the Form Designer or Class Designer.
>
>If your FormManager has no visual interface it can be derived from Custom too. Custom is a container, by definition if a class has AddObject()/RemoveObject() methods it's a container. The only limitation of Custom is that the VFP designer won't allow design time containership for Custom, you can't drop another class into it like you can a Container or Form class.
>
>>In fact I could convert the whole of my procedure file classes to
>>methods of a container, particularly if most of those classes are likely to be
>>used in most applications ?
>
>I'm a strong opponent to that position. I think UDFs, functions that have a broad application across several places still should be kept as functions. We still have str() and substr() functions, we don't have to use object method calling like _vfp.substr(). So no I wouldn't wholesale move a proc lib into object methods. I also don't have "A" huge proc file anymore. Each of my UDFs lives in it's own .prg, with the .prg name the same as the function so what I use in each app, is just what that app needs. I see UDFs as language extentions, and methods as the required intelligence of an object to carry out it's purpose.
>
>If you have functions that are appropriately attached to some class/object then by all means move that to a method. Especially if you end up with duplicated code across a couple of applications it's time to think about how that code could be generically put into a cApp.Method()