Just curious, I’m new to Lotusscript and maybe some of you experienced programmers have an opinion on this:
The command: FieldGetText.
I’ve been told that this command has limitaions, obvioulsly it does not work on Hidden Fields or work correctly on Multi-value fields.
I’ve been told(instructed) by several programmers NEVER, EVER to use this command, but to get field information using other methods.
Is this true? Do most experienced programmers NOT use this command? Since I’m new to Script I’ve seen examples and try to copy the logic and have used this successfully but as stated, programfmers tell me this is a NO, NO,NO…don’t use it, it only leads to trouble…lol
The people that told me this I have much respect for their programming capabilities but this one is new to me!!!
Any thoughts? opinions?
Thanks,
ccl
Subject: FieldgetText: A great Command
Actually it was Stan who pointed this command out to me. I love it! It has allowed me to get rid of the dreaded @DbLookup command and a few other @blahblah commands in my application projects. If there is a command to watch out for, especially in web applications, it is @DbLookup. It is useful but dangerous. The Text in the name is a clue that that is what you get as mentioned above by the other respondents. But once in the Script the Cdbl() gets you the number back if so desired.
Why don’t you ask the naysayers what the big issue is to them?
Cheers,
Steve
Subject: RE: FieldgetText: A great Command
NoteUIDocument.FieldGetText as a replacement for @DbLookup?
Wonder what your code looked like …
Subject: General theory - opinion question on LotusScript
Subject: General theory - opinion question on LotusScript
I can probably count the number of times I’ve used FieldGetText on one hand with a couple of fingers to spare. It’s mostly because of the limitations – it’s always text (whereas the field may be a number, date, etc.), and it’s always a single string (rather than an array of values). While the “NEVER!!!” crowd may be a bit alarmist, they do have a couple of valid points – particularly when dealing with date/time fields, number fields and multi-values. Date/time and numbers will be represented in text according to regional preferences, and it’s a lot harder to code for all of the text possibilities than for a “real” value. And multi-values can use any number of separators – but you can’t code for ALL of them, since some may be allowed in the data (as ordinary characters, not as separators) – it’s too easy for the field properties to get out of step with an action or a QuerySave or what have you.
Subject: Thanks Stan, you validated it…much appreciated!
Subject: RE: Thanks Stan, you validated it…much appreciated!
One use of FieldGetText is to retrieve the display value instead of the stored value from keyword fields that allow synonyms. It will also enable you to easily capture the text portion of unsaved RTFields.
Apart from that, I’m with Stan and hardly use it. There’s not much wrong with it, it’s just that most of the time back-end access is closer to what you need. Plus you can access items that don’t have associated fields using back-end methods.