Spanky's Place :: Help Request: R7 LotusScript interpreter change?

The following function is culled directly from my standard Utilities script library. I have been using this function, without error, since release 5 (Possibly 4.6, but I'm not sure). I recently upgraded from release 6.0.3 directly to 7 -which means that I don't know if this problem exists in 6.5.

The purpose of the function, in case you can't figure it out from the function name or in-code comments (ALWAYS COMMENT YOUR CODE), is to add a Variant to a Variant Array. A Variant Array is defined here as an array of variants, as opposed to a dynamic array. The code makes use of LotusScript's ability to handle dynamic arrays to resize the original array. Here is the code:

Function AddToVariantArray ( varSource As Variant, varElement As Variant ) As Variant

%REM

    This function will add the passed in element (varElement) to the end of the

    passed in variant array ( varSource ) and return the resultant variant.  

%END REM

    Dim varOut () As Variant

    Dim intPos As Integer

     On Error Goto ErrorTrap

    If IsArrayEmpty(varSource) Then

        Redim varOut (0) As Variant

    Else

        Redim varOut (Lbound(varSource) To Ubound(varSource) + 1 ) As Variant    

        For intPos = Lbound(varSource) To Ubound(varSource) 

            varOut(intPos) = varSource(intPos)

        Next  ' i 

    End If  ' Isempty ( varSource )

    varOut(Ubound(varOut)) = varElement

ExitPoint:

    AddToVariantArray = varOut

    Exit Function  

ErrorTrap:

    Redim varOut(0)

    varOut(0) = ""

    objUtilitiesInfo.AddError Err(), Error(), "AddToVariantArray"

    Resume ExitPoint  

End Function ' AddToVariantArray

As I said, this code has been in production for quite some time, and has worked just fine in every instance it was called. It is currently in production in many applications. Now that I've upgraded to R7, it throws Error #13, Type Mismatch when attempting to set the return value for the function.

ExitPoint:
AddToVariantArray = varOut <<== ERROR HERE
Exit Function

This is, as you can probably guess, going to be a pretty major problem when people using this code upgrade to R7. This doesn't just impact my current employer. I've been doing Lotus development for a long time, for several "major players" (both past and present) in the Notes/Domino consulting world; I have employed this function not only in my script library, but in just about every "Utilities" type library at every company I've worked for since R5. This means that this "break" could possibly effect hundreds of businesses; many of which I've never had any contact with.

Help Request

I'm ~~cross-posting this~~ (Can't login from hotel, will post later) to the IBM developerWorks Notes/Domino 6 and 7 Forum, and I'm considering opening a support ticket with IBM. Before I do that, would you, my Fellow Yellow Geeks (cool term eh? I just came up with that), please take a look at this, test it out, and let me know what you think? If there is a simple fix that I'm missing, and could add to this function to fix it, I'd love to know about it.

Thanks in advance,
-Devin

Wowsers! A Tag Cloud!

Comments

1 - I'm unable to reproduce the error you describe in Notes 7.0.1 - can you provide a testcase?

/lekkim

Posted by Mikkel Heisterberg At 03:32:46 PM On 04/10/2006 | - Website - |

2 -

Hey there Mikkel.

I just got back to my hotel room (it's been a long day). I'll put together a sample .nsf tomorrow and post it (either here or on the downloads page).

Thanks for your help,
-Devin.

Posted by Devin Olson At 12:31:37 AM On 04/11/2006 | - Website - |

3 -

I asked about this at the Ask the Experts: Technical Q&A yesterday, and Andrew Pollack provided an explanation. He asked me if by any chance this error was occurring when I was passing a specific column from a NotesViewEntry into the function. It turns out that I am:

myArray = AddToVariantArray (myArray, myNotesViewEntry.ColumnValues(myColumnNumber))

Andrew reminded me (I already knew this of course, but I was so focused on the error within the function itself that I stopped paying attention to the parameter I was passing) that the ColumnValues(n) could itself be an array. When working in Designer on a view, each column can itself display multiple values. In the particular instance where I was testing this function, I was passing specific column (as ColumnValues(n)) to the function. This column contained multiple values, which meant it was an array.

When I added the array, ColumnValues(n), as an element to the temporary array, varOut(Ubound(varOut)), I was in effect creating an array of arrays. The LotusScript interpreter could handle that, but chocked when I attempted to set the return value of the function to this array of arrays:

AddToVariantArray = varOut

It seems that this worked in previous versions (R5 & R6) because the type-checking wasn't as strong as it should have been. This has been corrected in R7. So essentially, my code worked because of a (for lack of a better term) bug; now that the bug is fixed, my code breaks. The honest truth here is that this function is poorly designed. I wrote it a long time ago, and it has worked well; but when I examine it now with a more critical eye I am forced to admit that it is bad code.

It's cathartic, I think, to look back at my old stuff and realize how much I've matured as a developer. I am now much more careful and thoughtful about my code than I was 20, 10, 5, or even 2 years ago.

I'm still not entirely happy with the situation. I would prefer it if the LotusScript interpreter could handle this without throwing an error, but at least I now understand why this is happening. More to the point, I have already started on a different set of functions that will replace this (yes, I'm going to publish the fix, yes, it will be free). I don't like the idea of having to do this kind of a fix, but it is necessary. It is better, I think, to have somebody (even myself) have to go through the pain & hassle of updating the code, than to have it blow up. A stitch in time saves nine.

However, unlike some other companies, I won't simply state that this function is now obsolete. I will add some code to the original function. I can't eliminate the problem, but I can enhance the code in such a way that it behaves better when this situation occurs. That way people who are using the function can decide for themselves whether or not to use the new function set.

Thanks again Andrew!

-Devin

Posted by Devin Olson At 12:23:45 PM On 04/13/2006 | - Website - |

4 - I think you are being too generous. I think it's a new bug, not a fix of an old bug. You're returning a Variant. It should not care what is in it. It should be able to return any type. An array of Variants in which each element contains a different type is valid. An array of Variants in which the last element contains an array is valid.

OTOH, I think you should be checking the type of varElement, because if it's an object you should be using a Set statement for the assignment just before ExitPoint.

Posted by Richard Schwartz At 09:38:41 PM On 04/16/2006 | - Website - |

5 - Richard,
you are (as usual) correct. My new "set" of functions should be able to handle this. I should have these finished & properly tested some time later this week.

Thanks,
-Devin.

Posted by Devin Olson At 08:50:57 PM On 04/17/2006 | - Website - |

6 - Did you ever come up with your fix for the multiple value column and using column.Values?

Posted by Marti At 11:30:35 AM On 04/26/2006 | - Website - |

7 - Sorry Marti, I don't have it ready yet. I've been a bit distracted with some other issues. I have also begun to suspect that this interpreter change is going be more painful than I first imagined -I think it may have ripple effects in other functions.

One of the problems I have discovered in trying to code around this issue is how to deal with different data types. As Richard pointed out, I should perform some type checking and use a Set statement where necessary.

Anyway, I'm going to have to put off working out this fix for another week (or two) -as I'm currently trying to finish up a pretty major project for work.

-Devin.

Posted by Devin Olson At 08:22:52 AM On 04/27/2006 | - Website - |