URL Encoding Data with set()

The "set" method hangs off the Base HostBridge object, usually referred to as just the hb object.  For encoding data, the default for set() is not to URL encode the data so we don't break existing behavior.

There are now 3 ways to control set()'s encoding behavior.

  1. Using the HBJS_ENCODE directive within HBR@INIT and/or HBGC.  The values for the HBJS_ENCODE_SET directive are 0 (do not encode) and 1 (URL encoding is enabled).  0 is the default; if 1 is specified, passed & and = characters are properly handled and work as expected. The value of HBJS_ENCODE_SET establishes the default value for HB.Session() objects that are created.
  2. On an HB.Session() individual object level. encodeSet property was added. It is a boolean value. It inherits the value from HBJS_ENCODE_SET as noted in #1. It can then be overidden.  This only affects the object instance it is set on.


var hb = new HB.Session();
hb.encodeSet = true;

3. On the individual set() call level. A 4th parameter was added to set() which specifies whether to encode or not. This flag if specified overrides the value inherited from #2 and #1.  The 3rd parameter is whether the parameter is persistent. The default is false and most people don't use this parameter very often.


var hb = new HB.Session();
// Run some transaction
// Need to update a field
// 4th parameter of true specifies encode
hb.set( "DBQNAM", "&12=", false, true );

If you have not been encoding the data for set(), #1 putting it in HBR@INIT with &HBJS_ENCODE_SET=1 will be the best option. This will fix the problem you are having and prevent it from happening with future scripts.

If some set()'s are already encoded, setting it to &HBJS_ENCODE_SET=1 in HBR@INIT may be best and then on the individual scripts were they are already encoded using #2 or #3, to turn off encoding so that the script still works the same.

Any of the above options will work; use whatever fits your situation best.