Hoi peter,
You're right, it is not a magical bullet. In your example of using a prg as a function, you stillhave a problem unless using macros to get arround that and that is not a very appealing solution.
I've never deepened myself in using project manager hooks, so I could not help in this. Sorry,
Walter,
>>Hi,
>>
DO FORM ("MYFORM")
>>REPORT FORM ("MYREPORT")
>>SET CLASSLIB TO ("Path\MyClasslib")>>probably is technically the fastest way to change the behaviour the way Peter wants to.
>>But a change like this can cut the other way as well: If the called function is deleted from the exe, you can have a problem later on, since the project managers check is circumvented.
>>Since the time I had to take over a program where this "methology" was used
everywhere to keep the pjx files empty of excluded files, I am a bit leery of the approach: there was no way no recreate the projects and more than a few projects were "out of synch" referencing unneeded parts where the developers were afraid to change manually. Re-Architecting was not easy.
>>Also porting with a "recreate" was not an option <g>. Since then I allow this way of handling references (if the customer is adamant on keeping it or working without excluded files in the pjx) ONLY with compile time constants, so that you can easily change these from strings to names and have the project managers checks enabled again. I definitely prefer excluded files.
>
>Thomas, as I read your words, you don't use this method if the choice is yours, right?
>
>Another problem is not nicely tackled by this workaround: We can't use quotes when using a function. Such a call only goes well if the function is in a library that has been declared with
>
set procedure to ("path\myproc")>I'm sure ( knowing him a little :) that Walter has succeeded tackling all consquences, but the method is not really appealing to me. Moreover, it is useless in the case of my legacy application.
>
>No, the fundamental solution must be laying somewhere within the possibilities of the project manager.
