>>>>There is only one strong reason for doing this (bundling multiple functions into one PRG), and it would be to implement abstraction / polymorphism.
>>>>
>>>>You would create the same function in two different PRGs:
>>>>EmployeeProgs.PRG -> FUNCTION Save
>>>>CompanyProgs.PRG -> FUNCTION Save
>>>>
>>>>If you are in the Employee.SCX, you set procedure to EmployeeProgs.PRG
>>>>If you are in the Company.SCX, logically set procedure to CompanyProgs.PRG
>>>>
>>>>Both screens can be generically calling SAVE(), while obviously the actual actions are different from each other.
>>>>
>>>>So if someone were to create a procedural code, that would be the way to go. Of course it does not make sense because with OOP you have much better ways to accomplish this, but in theory that is the one case where you cannot work with separate PRG's.
>>>
>>>Boy, would that make debugging hard. In an OOP world, where those are methods and thus context is clear, sure. But for procedural code, I'd consider that bad practice.
>>>
>>>Tamar
>>
>>Yes I agree, but it has been done in some projects I have seen.
>>
>>If you were to run your tool to split those functions into PRG's it would not work. That's why I said in this scenario you don't have another option than to stick to procedure files. I don't know of any other case where procedure files are absolut mandatory.
>
>I see. I thought you were recommending it. Instead, you're saying that sometimes you're stuck with it. Fair enough.
>
>Tamar

I would put it this way: I definitely would not recommend it to build a project like this, but the original idea behind it was quite intriguing. You could say it was a very early way of trying to adopt OOP principles in procedural code. The problem is that it is only a small part of OOP and with the lack of inheritance and encapsulation it does not get you where you want to be.

On the other hand, which other options did the FWP converter have? Since the procedures where inside the original SPR, when removing the screencode into the SCX, how could they solve the issue with the procedures?

For example convert MyForm.SPR to VFP Formset and SPR: MyForm.SCX and MyForm.SPR

1) Create Methods in MyForm.SCX and call the procedures inside the form with THISFORM.Save(). However some code used to call functions in other SPR files using Do Save IN OtherForm.SPR. So these references would have been destroyed, I suppose this is a No Go.

2) Create separate PRG's with the original SPR name plus function name: MyForm_Save.PRG, MyForm_Delete.PRG, and in the SCX prefix all function calls accordingly. This would have been in hindsight the best approach, because even a call like Do Save IN OtherForm.SPR could be changed into Do OtherForm_Save.PRG. It would have been much more work though to build, because the converter needs to track which functions are actually in scope and which not.

3) As they did in the end, move all functions into one SPR which calls the form. This is by far the least amount of work and surely does not break any existing code. So I guess this was the reason they went for this approach.

It would have been nice if they would have implemented Options 2) and 3) and let the developer chose how the files should be generated. I would have chosen option 2) then.