I have the following form setup:
Globals Declaration:
Dim doc As NotesDocument
QueryOpen:
Set doc = Source.document
A field, named Client, OnChange event:
updateModified “Client”
Sub updateModified (hanging off Globals):
Dim item As notesitem
Set item = doc.getfirstitem(“modified”)
But when it gets to the Set statement, it says “Object variable not set”. The doc is not initialized. Why not?
Thanks again, all,
-Jeff
Subject: More form scope questions
And - rather related to your original posting - don’t waste any efforts on declaring a NotesSession (or NotesUiWorkspace) object as a global variable. There is always just a single static instance of those two. Once you set a NotesSession anywhere in your code, any new dim/set will just return the very same object.
Using global variables sounds like a smart idea at first. But be sure: The more functionality you add to your code over time, the more troublesome it will get. If you restrict yourself to just the current database object and maybe one or two strategic views, you might get along for some time.
But even then your code will be more prone to errors. Even with Option Declare, Designer can no longer warn you, if you used a new variable without declaring it first, if there happens to be a variable of that name in global scope. You are not forced into finding a good structure for your code. For a good example of bad practice, have a look at the old Notes.net registration database available from the Sandbox. Try to make changes and additions to that code …
If you are just too lazy to pass parameters around, ask someone to kick your but and get going. 
If you prefer global variables for performance reasons, have a look into custom classes. Amongst other advantages, they can provide easy access to commonly used objects.
Subject: RE: More form scope questions
There is always just a single static instance of those two. Once you set a NotesSession anywhere in your code, any new dim/set will just return the very same object.
Sounds like I am wasting my time (have already wasted much of my time… grrrr!)
If you prefer global variables for performance reasons
Based on your first statement, how would making custom classes possibly gain any performance?
Thanks,
-Jeff
Subject: RE: More form scope questions
Certainly not with respect to the NotesSession. But of cource there might be other objects that are used again and again in your code (and which might be expensive to get, like e.g. NotesDatabase and NotesView objects. If you make them public properties of a class, they are available not only to code inside that class, but all code using this object. Still, the resulting code has much more structure.
Further time saving - development time that is - might be achieved in the future because of easier resueability of code. If you need a similar but not identical object in the future, you can derive a sub class from the original base class, adding new methods and properties and/or overwriting existing ones, without even touching the majority of existing code.
More on performance benefits: If you suspect that an object like a certain view might be used often, in the global variable approach, you would not only declare it inside your script library but also set it in the ScriptLib’s Initialize. But the more useful your ScriptLibrary is, the more often you are using it in different contexts, the higher is the risk, that not every form (or whatever) will need all of these global variables. Of course, you could only dim them in the library then and check whether they are already initialized prior to each use. Tedious, at best. With a class property, you could use lazy initialization in one place only (the property’s getter method) to take care of it all. If the property is never requested by the calling code, it will never be initialized. Otherwise, this will happen on the fly.
Andre just had a nice example on his blog:
http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/on-demand-oop?opendocument&comments
As pointed out in the comments, it can be done without using classes, but it doesn’t come so simple and naturally and requires more discipline.
Subject: More form scope questions
Put “Set doc = Source.document” in your PostOpen event, not QueryOpen.
Subject: RE: More form scope questions
OK, thanks.
When I do that, can I still access changes the user typed in fields via the doc object?