Debug fun: Folder names

Learned a lesson the hard way this week. debugging a problem where a code running against the


property of a mail file with over 7000 folders couldn’t locate certain folders even though the interface clearly showed the folders as being there.

The ultimate cause was as simple as stupid: The code that ran against the Database.views property used the (undocumented) function

folder =  getParentFolder()

to ask the user to select a folder. This function shows the user a folder select dialog and returns the selected folders as an array.

The users would select folders but for some reason the subsequent code retrieving the selected folders from the database.views wouldn’t always find them.

After some debugging the cause turned out to be that the folder names that the


Returned does a


on the selected folder names before putting it into the array. Problem was however that on creation of the folder (which was not being done manually but through a script in which the user was prompted for a folder name) the user sometimes added leading, trailing or double spaces in the name.

On normal (manual) folder creation, folder names are automatically trimmed to remove obsolete or trailing spaces. When created through script though this isn’t automatically done. So the actual folder names (as listed in Database.views) contained the names with the spaces while the returned array of folder names from the getParentFolder() didn’t.
As trailing spaces are almost impossible to spot in the interface this went undetected.

folder name problem

So while normally (on ordinary folder creation) this Fulltrim() by the getParentFolder() wouldn’t have been a problem, the fact that the folders were being created through script – and users were entering names with extra spaces – meant it caused a discrepancy between the name returned by the function and the name actually used. Or, to put it differently: the inherent ‘human’ factor wasn’t being filtered out.

Lessons learned from this:

  1. Debugging a mail file with 7000 folders is a pain in the …
  2. Do a Fulltrim() on any folder name created through code
  3. And finally… NEVER underestimate the inherent capabilities of users to cause havoc (roughly 1 in 5 folder names contained trailing and or double spaces)

Lotusscript TimeDifference & Long data type – Grrr….

Spent Friday investigating some freakish code problems. This one just blew my mind….
When assigning numbers to a data type what do you expect to happen when you assign a number to big to fit the assigned data type? Right, an overflow error. 

Well explain this then….

Ok, yes I know, you can solve it by using “difference# = notesDateTime.TimeDifferenceDouble( notesDateTime )” method which will return a double. I just can’t get my head around the fact that it didn’t return an error when it overflowed on 2,147,483,647 and instead continued up from it’s negative boundary (-2,147,483,648).
Or is this normal behavior for a Long data type??  I just hate it when I can’t logically explain something…

Code I used to test the effect:

Sub Click(Source As Button)
    Dim todayD As New NotesDateTime(Today)
    Dim AlteredDate As New NotesDateTime(Today)
    Set todayD = New NotesDateTime(Today)
    todayD.Localtime = todayD.Dateonly + ” 00:00:00″
    Set AlteredDate = New NotesDateTime(Today)
    AlteredDate.Localtime = AlteredDate.Dateonly + ” 00:00:00″
    For x = 24850 To 24860
        Set AlteredDate = New NotesDateTime(Today)       
        Call AlteredDate.AdjustDay(-x)
        If TodayD.Timedifference(AlteredDate)<0 Then
        End If

        Print “TimeDifference between: ” + TodayD.DateOnly + ” and ” +_

        AlteredDate.DateOnly + ” = ” + Cstr(TodayD.Timedifference(AlteredDate)) +_
        ” —- Days: ” + Cstr(x)       

End Sub

Update: I got this answer back through Twitter: “@FemkeGoedhart normal behavior for int/long. See” Thanks @Thimo! It explains it, although the logic of Lotusscript returning an error on overflow of Integers but not on Longs still eludes me….

Undocumented Method

I’ve been busy, really busy the last couple of weeks. Mostly with writing jobs I had to finish. I’m still working on an article and apart from that have been really busy with several reports and Functional Design documents so writing on my blog kind of fell in between.

But in the midst of all that writing I got a good old basic user problem to solve today. A notes 5.0 mail file (yes, I know this customer is really taking his time to upgrade) that had problems with it’s Signature and Archive settings. they seemed to randomly disappear. Fixup didn’t help and to rule out other problems with the profile information documents I decided to simply delete those. Now I’ve done that literally dozens of times with the calendar profile so knowing how to address that profile was no problem. I wasn’t sure about the Archive profile name though, so to be sure I dove into the code to see how it was addressed.

The agent opening the Archive settings called a method:

Call uidb.EditArchiveSettings()

Mmm…..not a method I am familiar with so I tried the help to see what it did. But I got no luck there, no mention of the method in the help files.

Unusual, Domino methods usually are pretty well documented but at the same time: No problem,  the notes community is so well organized that I was sure that I wasn’t the first one looking for this. So I turned to the biggest help file imaginable: The Internet.

Within a couple of seconds I  googled several entries noticing what I noticed, that the method wasn’t actually documented although it has been in use since Lotus Notes 5.0. But more importantly, they also provided me with the answer I was looking for: The archive profile is addressed as, yes you guessed it: “Archive Profile”.

Go figure. That simple and predictable answer could have cost me a lot of time hadn’t there have been the Internet. How I ever survived before…..I really don’t know!

ps. Deleting the profiles did the trick as I expected.