addedValues Plugin

...Powerful Free! Database Expansion for Manila

(1 or more words)

Get tropes here!
Click to see internals
Report bug

GSA Business

Viewable with Any Browser

Join Now

addedValues 1.0.11 Now available

Previous topic: Next topic:
inactiveTopic addedValues 1.0.11 Now available topic started 2007/12/16; 14:57:26
last post 2007/12/16; 14:57:26
user David Bayly - addedValues 1.0.11 Now available  blueArrow
2007/12/16; 13:57:26 (reads: 25200, responses: 0)
Disallow setting "Pause index loop ops after" to zero.

Fixed a bug where an imported form was not flagged as having a non
default layout, even though the layout was imported. If other
variables were later added or subtracted to the form, the layout
might be lost.

The help text for form layout picks a random variable to include in
the text; for multiple valued variables it didn't show the correct
syntax. Fixed. Additional text clarifies use of subscripted

manilaETP forms for editing messages use the implicit Manila
variables subject and body , usually with textbox qualifiers. .
These may now be required , by adding a 3rd parameter "required" for
example [[subject text(1,25, required;true]]. This change also
permits the 'Value Must be" attribute of these builtins to be changed
to a value more restrictive than any string (for example No HTML
might be useful for subject) and maximum length may also be specified.

A bug where builtin variables, such as image.shorcut, which can
appear in the layout of a messages form, were incorrectly assumed to
be "special" builtins like subject and body and implicitly added as a
form variable. Now, they are handled correctly as variables in the
report in which the form resides, and the current value is reported
as the form is built. .

The site specific localization macros ,macros
addedValueSiteMacros.dateAbbrevString ,
addedValueSiteMacros.timeString, were not declared as legal macros.
Now they are correctly defined when addedValues is initialized.

All occurrences of thread.sleepfor within addedValues have been
reviewed in the light of the results of the optimization of index
operations released in 1.0.10.

It is now possible to change a form element rendering by adding a
custom javascript event handler, for onBlur, onChange, onClick,
onDBLclick, OnFocus, OnkeyDown, onKeyUp, onMouseDown, onMouseOut,
onMouseOver, onMouseUp, onSelect. The edit fields to do this are
normally hidden, but are revealed by checking the Show Javascript
event handlerscheckbox. If the change refresh form checkbox is set,
the onChange handler cannot be altered, as addedValues makes use of
that event handler. addedValues dos not examine the javacsript you
supply, and its possible to affect the normal working of a form (for
example bypassing validation by submitting the form ) - all such
concerns are the users responsibility.

In ETP forms, the builtin variables subject body and attachfile are
implicitly included, and their rendering were not open to much
modification. The renderings may now be modified as extensively as
any normal rendering by adding any number of name:value pairs, where
the name can be one of class, style, lang, dir, id , tabindex,
accesskey, onBlur, onChange, onClick, onDBLclick, OnFocus, OnkeyDown,
onKeyUp, onMouseDown, onMouseOut, onMouseOver, onMouseUp, onSelect or
required. The values must be string values with no embedded &£123;, ] or
quote characters, or for the required name, true or false. for
example, [[subject textbox(1, 40,required:true, style:"color:green",
onchange:"this.form.section.value = this.value")]] .No syntax
checking is done for values.


- David Bayly. Programmer and digest reader. dbayly at udena dot ch
Digest Readers do it once a day.