Sometimes there are those things where the choices of Lotus to me are one big mystery and this is one of those:@DocChildren only works in a column or Title Formula nowwhere else… Why?
I needed this function to make an @If statements that prevents more than 1 response being made to a document. There are however no other @formula’s available for use in a formula to check the number of responses. So I created a view with @DocChildren in it and use a @DBLookup to get the value from the view. However @DBLookup skips columns with only @DocChildren (and the other alternatives) in it. WHY?
So I gave the row a value where I use a Field in my document like @DocChildren+UserNA. I create a field on my form where I do a @DBLookup for this value and get to see nicely: 1Martijn. So I finally found a number I can work with in a formula? NO! In the document properties I find that even though Notes shows the correct number, it saves: C0 Martijn. And that’s independent of the amount of responses. How did you guys do that, but more importantly: WHY?
Thanks. Regretfully this is a web application, which means that I won’t be able to use LotusScript in the foreground and have to do a lot of tricks to get a button to hide if there are any responses. I guess I have no other choice though…
Create a responses-only view with the first column sorted on @Text($Ref), and do a lookup to that view on @Text(@DocumentUniqueId). Hide the button if you get a valid return from the lookup.
Thank you all for the explanation and showing me the way to work around this problem. I went for the hidden view with the $Ref field, which works perfectly
I don’t see why that’s a problem. You can get the number of responses to a document in the WebQueryOpen agent for the form and then set a hidden (in field HTML properties, type [TYPE=“HIDDEN”]) field to the value, then execute your form Javascript accordingly, or hide/display your form actions/hotspots/hyperlinks accordingly. You’d then probably want to reconfirm the uniqueness of the response document on its save event, but that’s no real big deal either.
Unless you’re programming a highly utilized database where the possibility of simultaneous response documents being created to a single main document is quite high, my scheme above should work just fine.
@DocChildren (and the other “special” numeric fields in views) cannot be determined until the time the view is being built for display, and so are not stored in the view’s index, and cannot be looked up.
For example : If one of the children has a Readers field, so that you can see it but I cannot, the value of @DocChildren would be different for you that it would be for me.
These fields really only have a meaning within the GUI UiView that the user is looking at, and are calculated on the fly.
Since all response documents have a $REF field, which contains the UNID of their parent, you can make a view of all document that have a $REF and do a @DbLookup on that view to see if a response document already exists for any given document.
