Comments on: Edit Document Fields 5.1.0

By: Chad Schelfhout

Chad Schelfhout — Thu, 23 Feb 2006 00:50:00 +0000

Thanks for the feed back Jim. I was working on some additiona features my self this week. I will consider your thoughts when making my changes.

Just curious what you are looking to add. Maybe everyone could benefit from it. If you would like you can e-mail me.

By: Jim Fricker

Jim Fricker — Wed, 22 Feb 2006 10:53:00 +0000

I was not aware of the speed issue with literal lists so thanks for the education. I am all for performance optimisation when needed but not when it impares code readability for very minimal benefit. I would like to point out that neither of the examples I gave are inside the loop. But I am spliting hairs. You have every right to code this way. I am just trying to point out there are negative consequences of over using a “faster but harder to read” coding pattern, especially when the benefit is so small. The only reason I noticed it was because I was trying to add some new functionality to your code and all those @explodes were confusing the hell out of me so I ran out of time, lost patience, and gave up. Maybe I’ll have another go soon.

By: Chad Schelfhout

Chad Schelfhout — Mon, 20 Feb 2006 12:46:00 +0000

Yes, I am aware of that feature, and I purposelly avoided it base on Damien's post on Formula's dirty secret (http://damienkatz.net/2004/11/formula-languages-dirty-secret.html).

I would agree that it would make the code easier to read, but my goal is to make this to run as fast as possible since it can run over many documents. Thanks for the suggestion and the spelling correction.

By: Jim Fricker

Jim Fricker — Sun, 19 Feb 2006 15:25:00 +0000

Chad,

I'm not sure if you are aware but Notes formula has a notation for literal lists which applies to text, number and date lists. You just separate values with a colon. So instead of this code.

@If( DataType = @Explode( "Implode;Explode"; ArraySeperator ); ...etc...

You can write

@If( DataType = "Implode" : "Explode" ; ...etc...

Which is more compact and I think easier to read.

This notation applies to many places in the code including the assignment of the DataTypesCombo variable right at the start. No need for the @Explode and all those $ characters.

Jim

PS. Minor point but seperator is spelt separator.

By: Chad Schelfhout

Chad Schelfhout — Tue, 22 Nov 2005 05:35:00 +0000

Joel- Yes a simple form would work, but what is nice about this code is it all encompassing. All you have to do is add the code to a toolbar icon. There are other field editors out there that have some of these features. Here is one the Joe Litton did using LS: http://joelitton.net/A559B2/home.nsf/plinks/JLIN-6FS498

By: Joel Phelan

Joel Phelan — Tue, 22 Nov 2005 02:46:00 +0000

“Field value is limited to 255 because of the @Prompt limitations”

On this one, could you not simply use a dialog box with a single field on it and return it to the calling form? I have an application in which I am doing this with LS, but a formula implementation would not be difficult and would remove the limitation on characters.

By: Chad Schelfhout

Chad Schelfhout — Sat, 19 Nov 2005 03:47:00 +0000

Thanks Jim for the suggestions. I will correct the address book selection statement that you mentioned.

As for the adding of a basic formula option I have been pondering that for some time, just struggling on the implementation. The execution of just a formula almost fits with the toolbar functions http://www.chadsmiley.com/toolbarFunctions better, but it also edits fields. So the dilemma.

By: Jim Fricker

Jim Fricker — Wed, 16 Nov 2005 09:23:00 +0000

I often use the following very simple smarticon code to do updates to documents.

@Eval(@Prompt([OkCancelEdit]; "Formula Document Update"; "Please enter the formula to evaluate against the currently highlighted document"; ""))

I can then enter things like this into the prompt box

FIELD dateCreated := @Now; FIELD Creator := @Username; FIELD Subject := @ProperCase(Subject) + " plus extra subject text"

Which allows multiple fields to be updated, with a lot of flexibility of how the field updates are done. Perhaps this could be another option for your code? In other words, allow the user to enter a formula without specifying a field name or field value, and let the user supplied formula do all the work.

By: Jim Fricker

Jim Fricker — Mon, 14 Nov 2005 12:45:00 +0000

Incredible piece of code, and I learnt a lot from it. But there was one bit I did not understand. If a name multi value, or common name multi value or abbreviated name multi value option is selected then the user is prompted with @PickList([Name]). As far as I am aware this returns a multivalued list rather than a delimited string. In other words, it does not need to be exploded to generate a list as it is already a list. This seems to be taken into account for the name multi value option because the formula for this option does not include an explode. But for the common and abbreviated name multi value options the value is exploded on the colon character which seems strange.

I removed the explode from these two lines with no apparent change in the way it works

"CommonName Multi Value|@Name( [CN]; RawValue )$"

"Abbreviate Name Multi Value|@Name( [Abbreviate]; RawValue )$"

Great piece of work Chad!! Many thanks for sharing this.

By: Chad Schelfhout

Chad Schelfhout — Tue, 06 Sep 2005 17:05:00 +0000

David thanks for the feedback. I wish I could set the field type to Readers, Authors, or Names but Formula does not allow this.

I use the current contents of a field all the time. My favorite is to select multiple documents then move to the document that has the value I want to use then run the macro. This removes any typing mistakes and is less typing.

I did find one feature that I don't have and that is the check to see if a document is selected. I like that. I will also see if any more stream lining can be done with the dialog boxes.