Hello,please what is wrong in this LS when I evaluate causes error? I need to get number of list’s items:
Dim session As New NotesSession
Dim db As NotesDatabase
Dim view As notesview
Set db = session.CurrentDatabase
Dim doc As NotesDocument
Dim counter As Integer
Set view = db.GetView(“email”)
Set doc = view.GetFirstDocument
counter = Evaluate(“@Count(@Explode(“Subject”;”>“))”,doc)
thank you, JAKUB
Subject: Use variant as return type
always use variant when you set a variable using evaluate :
[dim result as variant]
Dim counter As Integer
Set view = db.GetView(“email”)
Set doc = view.GetFirstDocument
[result] = Evaluate(“@Count(@Explode(“Subject”;”>“))”,doc)
[counter=cint(result(0))]
This should work as long as you as your formula returns a number.
You might also test if result(0) is not an empty string value.
Hope this helps
Renaud
Subject: Thank you 
Subject: Ok, I’ll bite.
First of all, the limit you claim of a 255-character max for Evaluate doesn’t exist and hasn’t since R5.
Terseness - @Middleback(), @SetField(), @DbLookup(), etc. are much easier to read as small snippets in @Formula than their equivalents in LS, Java, or SSJS.
@DbColumn - it’s slower and much more spammerific to use NVN than an @DbColumn. NVN will give you category totals and could theoretically handle more rows, though.
Context - There’s an @Formula version of Evaluate, @Eval. This means that blocks, field defaults, etc. are trivial to implement via @Formulas.
Agents - A simple @Formula agent is almost always faster than its simple LS/Java equivalent.
Garbage Collection - I just threw this in because @Formulas have much better garbage collection than N/D’s implementation of Java (kind of sad if you think about it). This doesn’t really apply to LS though.
Subject: re: Ok, I’ll bite.
First of all, the limit you claim of a 255-character max for Evaluate doesn’t exist and hasn’t since R5.You’re right. It’s still a bit fuzzy, but I think I was recollecting an issue with @Eval, and the limit was likely imposed by additional formula that was selecting the formulas to run from configuration documents. Still trying to recall the exact details. As you might have guessed by my attitude, it’s been a very, very long time since I’ve coded a large process using formula. 
Oh come on…they’re not THAT much smaller.
I did some test on a view with 2500 docs, representing just over 35k of data to be retrieved. @DbColumn is fast both locally and on a server. LotusScript was nearly as fast locally (nearly one second) but needed about 10 seconds when the code was accessing a server. So it’s not LotusScript per se, but the fact that it has to access each view entry individually from the server that makes it slow, as oppose to @DbColumn, which, I’m guessing, has a server component to it so that it can make only one request to the server.
In any case, for UI functions I’d just use picklist and not worry about the 64K limit, or a paging system and show users 25 items at a time. That usually responds instantly to the users. It’s too bad that IBM abandoned LotusScript. I’m sure we would have a column function by now if they hadn’t.
I guess. I stopped using default, translation, and validation formulas a long time ago. I don’t use Pages much, but that’s just me.
Probably right. But you still can’t debug it. When formula doesn’t work, it’s always a guessing game as to what’s wrong. And I’ve seen people spend a very long time guessing at problems.
Probably because formula can’t create any variable more complex than an array of dates. Who knows how messy things might get if formula could work with objects. Should we petition IBM for object-oriented formula?
Subject: Terseness
Oh come on…they’re not THAT much smaller.
Really? You’re telling me there’s no big difference between:
@SetDocField(targetUNID; “myfield”, “1”);
and:
Dim contextDoc as NotesDocument
Dim targetDoc as NotesDocument
Set contextDoc = (whatever)
Set targetDoc = contextDoc.ParentDatabase.GetDocumentByUNID(contextDoc.targetUNID(0))
targetDoc.myfield = “1”
Call targetDoc.Save(False, False)
? And with SSJS you can’t use dot notation to reference items, so you’re talking about even longer code needed.
@Formula’s terseness and similarity to Excel is one of the biggest reasons to use it – for small snippets of code. I’ve got an army of power users that can really get what they need done with @Formulas, but they’d be far less productive dealing with any other language.
Subject: Actually…
…it’s worse than that, as failure of GetDocumentByUNID raises a bad-unid error instead of just returning nothing, so you have to add an On Error process to trap error 4091!
Well, I guess we simply have different points of views. you may feel that terseness and similarity to Excel is a good reason to use fomula, and I feel that the versatility, power, and error handling abilities of LotusScript far outweigh any advantages formula might have in other areas. To each, his own!
Subject: It definitely depends…
We run the single most complex Domino web app in the world (I’m not joking). It’s got TONS of OO language coding.
But it’s got lots of configurable workflow areas where users can configure and tweak small behaviors, and @Formula’s the king there.
And there’s no need to “On Error” the GetDocumentByUNID call… after all, that should never happen, right? 
Subject: re:no need…Yes you’re right. I stand corrected (EOM)
Subject: Seems like Willy is kind of LotusScript Knight … fight for your right to party
Subject: DON’T USE EVALUATE!
Only bad programmers use evaluate. There might be an argument to use it for @DBColumn, but even that is questionable. Otherwise, you can do everything you need with LotusScript AND debug it when you have a problem.
Dim counter As Integer
Dim doc As NotesDocument
Dim session As New NotesSession
Dim SubjectAry As Variant
Dim view As notesview
Set view = session.CurrentDatabase.GetView( “email” )
Set doc = view.GetFirstDocument
SubjectAry = Split( doc.GetItemValues( “Subject” ) , “>” )
counter = Ubound( SubjectAry ) + 1
Subject: Actually, there’s several cases where Evaluate is great.
But yes, debugging is more difficult.
Subject: Name three.
Subject: Dynamic coding is one …
Ha ha, I love when programmers get categoric
One reason to use Evaluate would be where the @formulas lives in configuration documents and similar. The code can be changed without having to be a designer
Subject: here’s a link to tell you more about Willy’s answer
Don’t bother arguing with Willy.
Roll on the day when he’s out of this forum
Subject: As expected, Watka makes a comment that has little to do with the discussion.
Subject: Nope. Use Execute instead.
You can do the same with LotusScript using the Execute statement. This is better than Evaluate with formula because Evaluate is limited to some 255 characters or so (I forget the exact number) whereas Execute isn’t.
Also, while you can’t debug Execute script during execution, you can certainly debug it as you’re developing the code. And if worse comes to worse, you can always replace the execute statement with the problematic code in your test environment to resolve any issues. You can never do that with Evaluate.
So for dynamic coding, LotusScript is still better than formula.
Subject: No 255 limit now?!? Where do you have that from? And - If your @formula code works … shouldn’t it be used?
As for speed, why not jump on the Notes C API bandwagon?? Much closer to the core than LotusScript ever will be
Subject: Evaluate & Execute
"And - If your @formula code works … shouldn’t it be used?"No. Just because it works now doesn’t mean it will always work. Some other programmer may make a mistake in some other code, document fields that should be numeric are now saved as text, and your “working” formula grinds to a halt. Now you have to figure out what’s wrong. How do you debug it? By sticking to your old formula, you’ve just thrown away a major benefit to LotusScript.
And for maintenance purposes, it’s easier to find people who know VB and can start updating or migrating LotusScript, than it is to find people who know formula.
By far and away, the biggest use of Evaluate I’ve seen is to act as a crutch for developers to not have to learn LotusScript.
C API?? Are you nuts??
Erik C. Brooks is correct in that there doesn’t appear to be a 255 character limit on Evaluate. I’m trying to review now why I thought that. I think I might have been thinking of @Eval where the argument was extracted using even more formula, and the process imposed a limit of 255 character strings. I don’t have the code anymore so I’m trying to remember what it was.
Still, even without the limit, LotusScript is better for dynamic coding for the other reasons given, as well as the fact that you can have UI functions in Execute but not in Evaluate. In fact, you can perform just about any operation you want.
Sub Click(Source As Button)
Dim script As String, retcode As Integer
script$ = {Sub Initialize
Dim documentnode As Variant
Dim eobject As Variant
Dim fullxmlfilename As String
Dim flag As Boolean
Dim parser As NotesDOMParser
Dim stream As NotesStream
Dim thisns As New NotesSession
Dim urldoc As NotesDocument
Dim urlstring As String
urlstring = |http://local.yahooapis.com/MapsService/V1/geocode?appid=YD-9G7bey8_JXxQP6rxl.fBFGgCdNjoDMACQA--&street=701+First+Ave&city=Sunnyvale&state=CA&output=xml|
Set urldoc = thisns.CurrentDatabase.GetDocumentByURL( urlstring )
fullxmlfilename = Environ$ ( "TMP" ) & "\" & "returned.xml"
If Dir( fullxmlfilename ) <> "" Then Kill fullxmlfilename
If urldoc.HasEmbedded Then
Forall item In urldoc.Items
If item.Type = ATTACHMENT Then Set eobject = urldoc.GetAttachment( item.Values( 0 ) )
End Forall
Else
Msgbox( "no embedded objects found")
Exit Sub
End If
Call eobject.extractFile( fullxmlfilename )
Set stream = thisns.CreateStream
flag = stream.Open( fullxmlfilename )
Set parser = thisns.CreateDOMParser( stream )
Call parser.Parse
Set documentnode = parser.Document.DocumentElement
Call stream.Close
Kill fullxmlfilename
msgbox( documentnode.nodename )
End Sub}
retcode% = Execute ( script$ )
End Sub