Mike,

>Is it really that common? I hope not. For some reason, that technique irks me, it works:

>but it could get completely unobvious in writing and debugging. And while I see how it could make components that float between frameworks that have different oApp object references, the level of sohpistication is silly. I doubt the objects would have the same PEMs making wether or not is could be referenced pointless.

I probably wouldn't use it to define the object reference name of the app object, but for APP_CLASS and APP_CLASSLIB, yes -- to allow the flexibility to swap out a class and/or classlib with just a changed entry in the .h file (or in the main prg) without having to change every place in the code that instantiates it.

I've just been working with Rick's Web Store sample app, and my specialized subclass of his invoice business object class was plugged in just by changing one DEFINE in the .h file, since he referred to the constant all the way through his code in every CREATEOBJECT statement.

However, even the object reference name as a constant makes sense in a generic framework where you might already have your own app object scheme that you want to plug into the framework and not break existing code that refers to it by a certain name. That's probably why the framework writer in this case did that.