I've been working on a view that allows in view editing of one column that displays the Subject field.  I added validation to the InViewEdit event to ensure that the Subject column value entered isn't blank (or empty) before the change is saved to the document.  My code prompts the user to enter the missing value:

After which the view displays the following error:

There is a work around on LDD that does prevent the "Error validating" message from appearing, but the column being edited loses focus.  I just tested this in 8.0.2 and the client still works this way.  Sigh.  I guess some things never change.  At least I remembered why I never bother with in view editing.

(0)

One of my clients reported the following error when composing a document:

I created the database with Designer 6.5.5 because all of the users throughout the company use Notes 6.5.5.  However, there are a few users that are testing Notes 8 Standard.  For some reason, the Notes Lotusscript compiler didn't like the following Lotusscript function defined in the form (Globals) event:

Function isValid () As Boolean

According to the Domino Designer Help:

Empty parentheses not legal on:

You included empty parentheses in referring to a variable of type Variant or an undefined function or sub (which LotusScript interprets as a reference to an implicitly declared variable of type Variant).

This didn't make any sense to me, so I resaved the form in DD 8 and tried composing a document with the form again.  This resolved the error, but left me wondering how many other forms I'd need to resave to fix this issue when my client moves to Notes 8...

(5)

I recently needed to convert some LotusScript code that used Trim() to formula code. The reason for this was so that the code will be run when I use NotesDocument.ComputeWithForm. Here's a sanitized version of the LotusScript code:

Sub Initialize
	
	Dim pre As String
	Dim fst As String
	Dim mdl As String
	Dim lst As String
	Dim suf As String
	Dim username As String
	Dim username2
	Dim nameStr As String
	
	pre = ""
	fst = "Michael"
	mdl = ""
	lst = "Sobczak"
	suf = ""
	username = Trim$(pre & " " & fst & " " & mdl & " " & lst & " " & suf)
	
End Sub

The above code uses the Trim() function. Trim() doesn't remove redundant spaces between words, so the result is that my name has two spaces between my first name and last name, like this: "Michael Sobczak". Here's the formula version of the same code:

pre := "";
fst := "Michael";
mdl := "";
lst := "Sobczak";
suf := "";
username := @Trim(pre + " " + fst + " " + mdl + " " + lst + " " + suf);
@Return ( username );

The @Trim() function removes all redundant spaces between words. So now my name has only one space between my first name and last name, like this: "Michael Sobczak" Why is this a big deal? Well, the form in question logs individual field changes to the document history section. When the above formula runs in the Input Translation event, the username is recomputed and the form sees the field value as having changed and logs the change. So the only solution I can think of is to run some cleanup code against all of the existing documents to fix the original problem introduced by Trim(). If only the original Lotusscript code had used FullTrim()...

(0)

One thing I always do before I begin updating complex code is document the flow of the code.  My rudimentary way of doing this is to start with the initial subroutine and indent each subroutine that is subsequently called, like this:

Initialize()

getProfile()

calculateRate()

updateDocs()

END OF CODE

I document my findings either on a piece of paper or in Wordpad, depending on how complex the code turns out to be.  (I'd record this in a Journal entry in Notes if the Lotusscript debugger didn't lock the Notes client--ugh!.)

If the code is particularly complex I'll use the Lotusscript debugger to figure out what's calling what.  Essentially I'm coming up with the call stack for the code for normal code execution.  I'm guessing that there must be some standard practice or way of doing this sort of documentation.  I've tried to use Visio to do this in the past, but Visio seems like a lot of overhead (not to mention cost) to do what is a fairly basic task.  Does anyone out there have a better or more elegent way to document subroutine calls?

(3)

I've been researching a problem that appears to be related to Windows Vista, and am looking for help/guidance from any Notes <-> Office integration experts out there in Notes community.

When I run the following code within Windows XP, the Excel spreadsheet is opened and maximized on the user's desktop.  However, when I run the same code on Windows Vista, the Excel spreadsheet is opened but minimized in the Task Bar.

Const FILEPATH = "c:\Temp\Issues.xls"
 
Dim o As Variant

Dim oWB As Variant
 
Set o = CreateObject("Excel.Application")
 
o.EnableEvents = False
o.DisplayAlerts = False
 
Set oWB = o.Workbooks.Open ( FILEPATH )
 
o.Visible = True

I know I can use ActivateApp to resolve this, but that would require updating a lot of existing code.  Is there is a setting or a preference in Windows Vista that would restore the behavior users had with Windows XP and prior?

(3)

Notes 6 introduced the ability to run an agent in a background thread. You enable this behavior by checking the Run in background client thread property in the Agent Properties dialog box:



Since no good deed in Lotus Notes goes unpunished, Domino Designer displays the following message box every time you save the agent:



As a result, users can run this agent in a background thread if the agent the agent is executed from the Notes Actions menu:



or using the following formula code:

@Command ( [ToolsRunMacro]; "Run me in the background, baby!" )

What if you want to trigger the same agent via LotusScript? Unfortunately, LotusScript will not run an agent in the background, regardless of whether the above agent property is checked.

However, you can hack your way around this limitation by having your LotusScript code open a form in the Notes UI that executes the above @Command in the Postopen event. Provided that your LotusScript to opens and closes the NotesUIDocument immediately, users will never know what's happening.

All credit for this nifty trick goes to Chhanno L Verma, who answered his own question in the Notes/Domino 6 and 7 Forum.

(0)

I've been using the dynamic class loading technique popularized by Bill Buchan since June '06. (If you're unfamiliar with dynamic class loading, I gladly refer you to Bill's BP312 Object Orientated LotusScript Techniques and Tricks presentation.) I've been extremely happy with the results with one exception. One database I've been developing off-and-on for the past year seems to have a problem with the classes I load dynamically in my agents. Whenever I change the classes, the agents that instantiate objects based on the classes return the following error:

$EXECUTE$+4: Class or type name not found: REQUESTFACTORY

Before I continue, I should state that LND 6.5.4 is being run on all Notes clients and Domino servers where I work. Yes, I deserve much pity and envy all of you who are using LND 7!!!

I tried re-saving the script libraries and then re-saving the agents that used the script libraries, and vice versa. The only way the error went away was when the server was rebooted. After the reboot, my agents were able to dynamically load the classes without a problem.

Since this project was put on hold since last September, I forgot all about this problem. Until today, that is.

Over the past several weeks, I've been testing the application and cleaning up the code when necessary. Lo and behold, the above error reared its ugly head again. I tried re-saving the script libraries and agents again, to no avail. Just as I was about to ask the Domino administrator to reboot the server, I decided to take another look at the script libraries containing the custom classes. And I had one of those epiphany moments that make you want to get up and leave work immediately, because the rest of the day just couldn't possibly get any better!

As I opened each of the eleven script libraries that contained custom classes, I noticed that three of them prompted me to save them when I closed them, even if I didn't touch the code at all. It turned out that for each of the these three script libraries, I'd added a comment to the script library's properties, like this:



On a hunch, I removed the comments from these script libraries and re-saved them. I retried my agents and the error was gone. Whoo-hoo! Talk about a Notes quirk!!!

(2)

I'm working on some code that checks all Resource documents in a view. For each Resource document, the code creates a custom LotusScript class called "Resource". If the Resource document has a Request child document, the code instantiates an object based on a custom LotusScript class called "Request". (Both the Resource and Request objects are defined as Variant, by the way.) After processing the "Request" object, the code attempts to delete the "Resource" and "Request" objects. The problem is that sometimes there is a Request object and sometimes there isn't. For example, if the code attempts to delete the Request object before it has been instantiated, Notes returns the following error:

Error # 193 - Illegal DELETE

If the code attempts the delete the Request object after it has been instantiated and deleted, Notes returns this error:

Error # 91 - Object variable not set

The answer is to check to see if the Request variable is an object first, then check to see if it is Nothing, like this:

If ( Isobject ( res ) ) Then
	If ( Not ( res Is Nothing ) ) Then
		Delete res
	End If
End If

Of course, the obvious question is why I'm bothering to delete these objects at all, when LotusScript automatically deallocates objects for you. Well, I thought I'd be a responsible citizen and immediately clean up after myself when instantiating objects within a loop. Call it Post Traumatic Stress Disorder brought on by not calling recycle() on Domino objects instantiated within either a for or a while loop within Java code. I know the two languages are completely different and handle object deallocation differently, but I'm concerned with assuming Notes will do the right thing and having my application crash the server once its in production and being used by 2k employees on a daily basis. Also, the example code contained within "Appendix B-2: Dynamic Script Library Loading" of the Performance Considerations for Domino Applications IBM Redbook show the custom object being deleted, and I'm assuming that that's being done for a reason...

(0)

A new feature with V6 is Soft Locking. Soft Locking is a server setting that prevents a user from editing a document someone else is currently editing on the same server. Until today, I didn't know that you can't copy a document that has a soft lock using LotusScript. I wrote an agent that copies documents from one database to another. The code looks like this:

Dim session As NotesSession
Dim currDb As NotesDatabase
Dim qaParent As NotesDocument
Dim prodParent As NotesDocument
Dim qaDB As NotesDatabase
Dim v As NotesView
	
Dim i As Integer
	
On Error Goto errorHandler
	
Set session = New NotesSession
Set currDb = session.CurrentDatabase
	
Set qaDB = session.GetDatabase ( "QAServer/CMA", "somedb.nsf" )
	
Set prodDb = session.GetDatabase ( "PRODServer/CMA", "somedb.nsf" )
	
Set v = qaDB.GetView ( "Main" )
v.Refresh
v.AutoUpdate = False
	
Set qaParent = v.GetFirstDocument
	
Do Until ( qaParent Is Nothing )
	
	i = i + 1
	Print "Processing doc: " & i
	Set prodParent = qaParent.CopyToDatabase ( prodDb )

		
	Set qaParent = v.GetNextDocument ( qaParent )
		
Loop
	
Msgbox "Processing complete"

End Sub

However, every time I ran the code, I kept getting this error message:



So I needed to find the user who had a document open in edit mode and have them save and close it. Then my code worked fine. Nice that this is documented somewhere... ; + )

(2)

In spite of what's documented in the Domino Designer Help database, NotesDocument.ComputeWithForm evaluates all Computed When Composed formulae in a form, in addition to any Default Value, Input Translation, and Input Validation formulae present.

So how was I punk'd by this undocumented feature? When ComputeWithForm is invoked by a Notes 4.6 client, Computed When Composed formulae are not evaluated. Since the company I work for still has a handful of Notes 4.6 users, the documents they were creating programmatically did not have field values for any of the Computed When Composed fields when the code they invoked called ComputeWithForm. All I had to do to resolve the problem was update the code to manually set the field values, but still, whey does Notes 6.5 evaluate Computed When Composed formulae at all? Since it obviously does, why doesn't it evaluate Computed formulae as well?

(2)

Since I started as a full-time employee for my current employer last August, I've had more work than I can shake a stick at. In fact, I could shake sticks with both hands and it wouldn't make a difference! An example of this is a project that has been on the back-burner for the past eight months. The project involves creating a web-enabled Notes application that will serve as the mechanism whereby employees will be able to search for and request books, videos, DVDs and audio cassettes from the Training Resources department. Essentially, the application will function as a library database. The database was created a contractor on staff before I arrived, and it was roughly 80% complete when he left.

When the contractor was working on the database, the only Domino server in production with the HTTP task running was R5. Since the application was supposed to have been rolled-out in a month or so, the contractor couldn't reference any of the document locking features available in V6. The Domino server was subsequently upgraded to V6.5 last September, making it possible for me to upgrade the application so that it uses document locking to prevent replication conflicts when resources are being checked out and checked in. As luck would have it, I was assigned to several high-priority projects for various clients within my organization, and its only now that I finally have a window where I can start working on this database again.

I have used document locking before, in several Notes client apps, but never for a Notes application accessed only by web browsers. While the Notes client will automatically lock a document once its opened in edit mode, the Domino server does no such thing. Instead, you need to code all of the document locking and unlocking yourself. This requires performing the same lock and unlock statements over and over again. Since document locking has been available since V6 was released back in October '02, I thought there would be a multitude of articles on this topic. This was not the case. The Lotus Advisor articles I found both used manual locking techniques that were the only way you could implement document locking back in the R4 and R5 days. James Ray's article in the September/October issue of The View provides an excellent examination of how document locking works in all possible scenarios. He does provide LotusScript code that enables you to programmatically work with document locking, but I felt I'd need to add more code for it to handle all of the things I would need.

Fortunately, Chad Schelfhout took the time to create a custom LotusScript class that contains all of the methods and properties I could ever ask for. I've already started adding it to several of the LotusScript agents that will be invoked by web users to edit, check out and check in library resources. Way to go, Chad!

(3)

Working with an existing multi-value field is challenging enough. But what if the multi-value field doesn't exist yet? For example, you're creating a new Notes document via the back-end classes, and one of the fields needs to contain multiple-values. Worse yet, the field needs to contain Date/Time values.

One problem with working with Date/Time fields via the back-end is that unless you're careful, you'll end up with values that include midnight, like this:

1/30/2006 12:00:00 AM
2/15/2006 12:00:00 AM
2/30/2006 12:00:00 AM

In some situations, it may not matter if the field values include the bogus midnight time. These values can cause problems with documents that are displayed in a calendar view. Personally, I hate sloppy coding. Side effects like this must be corrected, to keep Notes applications from being jettisoned to the Island of Misfit Apps.

For an example of how to create a multi-value date field without midnight times, click on the Read More link below...



(3)

One of major problem with Rich Text Fields is that changes made to them in the Notes UI are not visible in the back-end Notes document until after the change has been saved in the Notes UI. This makes validating that a Rich Text Field is not empty particulary difficult. Sure, you can check to see if the field contains a text value or not, as is described here on the IBM developerWorks site for Lotus Software.

But what if you need to verify that the Rich Text Field contains something, whether its text, a doclink, an attachment, an embedded object?

If your form validation is invoked within the form's Querysave event, it won't work due to the problem described above. However, you can check the Rich Text Field after the document has been saved in the Notes UI. So, you could run your validation code in the Postsave event, or in an agent called by a button that performs the save. For more details on how to do this, click Read More below...




(2)

I just verified this in the Lotus Domino Designer Help db. I never new this. I've created Lotusscript classes before, but never ones that inherited from other classes. Of course, I didn't have a need to explore this further until I finished the specs for a new application. The application will have four request types:

• New Hire Request
• Application/System Change Request
• Employee Information Change Request
• Termination Notice

Each request type will spawn from one to fifteen individual task documents. Since there will be substantial overlap between the request types and the tasks, using class inheritance will make it possible for me to treat a request object like the supertype in in some instances and like a subtype in other instances. The same will also hold true for the tasks. Best yet, I won't need to create duplicate versions of subroutines and functions in other script libraries. (For those of you who are familliar with object-oriented programming concepts, I forgive you for yawning.)

The only thing I wish Lotusscript would let you do is override class members. For example, you can only define one constructor (in either the superclass or a subclass). And you can't redefine a class variable in a subclass. Also, you can't have two methods with the same name, even if the method signature is different. Because of this, I don't think Lotusscript is really an object-oriented language. But, for my needs, it should be adequate.


(0)