> I just modified a piece of code today. It has public vars and I know the original programmer knew not to do it, but was in a hurry and used them out of "habit". He's a really good programmer and I'm happy to be working with his caliber again.
>
> There's a line of code in this app which reads...
>
> ON SHUTDOWN DO SHUTDOWN.
>
> Now during debugging this little line can get a annoying. First off, PROCEDURE SHUTDOWN was in a .PRG. Once the app stops and SET PROCEDURE is cleared, trying to exit gives the error message Based on the pre-existing code, I thought I could just add another public var. Then I remembered a better approach.
>
> By avoiding public vars - as an engineering principle, I created a private var in the main part of the program. I instantiated an object based on the memento design pattern to this private var. Mementos remember things, like ON("SHUTDOWN") during init and resets them when the variable is released like when the app stops. So now, no more ON SHUTDOWN related problems and no public vars. Besides, a public var would have stayed 'alive' after the app shutdown. So ON SHUTDOWN would not have been reset until I release the public var.
>
> I guess the point is, by avoiding a bad practice and collecting good practices, you can do some pretty cool stuff.
>
> Mike Yearwood
>
www.foxridgesoftware.com> President: Toronto Ontario FoxPro User's Group
Mike,
I don't quite get it: what having PROC Shutdown in a different than Main PRG module has to do with with PUBLIC vs. LOCAL/PRIVATE case at hands? I would rather have this PROC Shutdown moved into Main and be done with it, honestly!
Moreover: it may be the matter of habit, but I would rather have all these RELEASE and SET bla-bla-blah TO [space] commands right before the QUIT command (or CANCEL, if that's the case) in the main proc in Main, rather than in some sub, let alone in another module. ON SHUTDOWN proc should handle primarily saving data on disks and closing the tables, IMHO, coz this is where the real damage usually occurs.
Regards,
Ilya