There should be a form for user login that calls a user validation object. It's not part of the validation object. Some study of SOLID Object Oriented Design and Domain Driven Design should help you with good OOP understanding.

>Dragan and Craig,
>
>Thanks once again for your replies.
>
>The reason for this thread is this. I was thinking of having my App object have a VerifyUser() method, which will fire up a form to ask for the user's password after a time of non-activity, similar to Windows XP's screen saver feature. Consequently, my App class will now have VerifyUserUIClass, VerifyUserClasslib properties upon which to instantiate the UI object.
>
>Not a good idea? Kindly do share your insights on this.
>
>Dennis
>
>
>
>>>Hi Experts,
>>>
>>>Are Application Objects typically based on the Custom class?
>>>
>>>If so, then, being based on a non-visual class, can it show or instantiate a UI class - in my case, a Form object?
>>
>>The UI objects are not app's members. The forms are standalone objects, basically members of _Screen.forms collection, but that happens automagically, behind the scenes. You don't do oApp.addobject("oform1", "myForm"), you do loFrm=createobject("myForm").
>>
>>You can actually do it anywhere, it's just that you can't have a visual object as a _member_ of a non-visual one, i.e. a visual* object can't have a .parent that isn't a visual object.
>>
>>*mind you, visual objects are those that have a .refresh, .fontname and other GUI-related properties. It doesn't matter whether they are defined in a .prg or in a .vcx at all.