PG Software Development

Hi Clifton,

Just a couple of things. Neither is really a problem because I have workarounds for both of them.

In this reply https://www.pgsoftwaretools.com/forum/viewtopic.php?f=10&t=278&p=1013&hilit=password#p1013 you suggest using userProperty() to create a password field. I interpret this as being something like
tbfunction_userProperty("[name of field]", "type", "password") but I have never been able to make it work. Instead I use an html containing a password input loaded into a field by pgGotoURL

I also need to use the propertychange event in a single-select listbox but I haven't been able to do this in an XML file. Is it possible? It's absolutely not a problem as I can just do this in a TB actions sequence instead.

John

Regarding the first issue:

It is important to understand what ToolBook does to text fields on export.

• Text fields that are NOT editable in the exported HTML will be exported as <span> elements. You cannot convert a <span> element to make it editable nor can you mask the input in the field with type="password".
  
• Text fields that ARE editable in the exported HTML content are of two types.
  
  1. The first type is a field which is set to allow word wrap. These fields are exported as <textarea> elements in the exported content. You cannot mask the input of these fields by setting type="password" as it will have no effect.
  2. The second type is a field set to single line. These fields are exported as <input type="text"> elements and these CAN BE MASKED by using userProperty() to set type="password".
My guess is that you are trying to convert a <span> or <textarea> element to act like a password <input>. In this case you are trying to make an orange look and taste like an apple. There really should be no reason why you need a separate HTML page set with pgGotoURL() to handle user credentials. My LearnToType.Today program uses alternating behavior on <input> elements in its password recovery mechanism.

Regarding the second issue:

We would need to know more information about how you are trying to use the onchange event on your elements. In HTML, the onchange event is not fired for every object. Sometimes, onchange events are fired only when the focus changes from one input to another. For comboBoxes, the onchange event is fired when the selected option is changed. So it is important to know what you are trying to accomplish. Sometimes, rather than an onchange event, all that is needed is a keyup, keydown, or somewhat less often a keypress event. For editable fields, the PowerPac function validateField() is a powerful what to capture and analyze what is being typed into a field. I use it quite a lot on my editable fields.

Thanks for your reply.

Password: the field in question is definitely a single line type. Perhaps the fact that it incorporated into a mobile group using mergeTBObjects and createDraggableObject may be having and adverse effect.

Property change: the object is a single-select listbox which needs to react when the selected item changes (and it does but only if I use the TB actions system).

John

Here is a working example of merging objects and using userProperty() to set the password mask.
Everything you see is handled in an XML file. No Actions were created.

So what is the deal with the onchange event and comboBoxes?

• You should NEVER use the onselect event in the Actions Editor for list boxes and comboBoxes. This event is only supported if you set the options list in the Actions Editor. As soon as you dynamically change the options, the onselect event becomes useless as it never fires.
• However, you can always use the on property change event in the Actions Editor. Once this fires, you can use setComobBoxOption() to find out the item selected.
• In the example above, I've used XML to dynamically create the list items in the comboBox. When you change an item, the onchange event fires (which is almost exactly the same as on property change in the Actions Editor). Once the onchange event fires, the XML uses setComboBoxOption() to get the text of the selected option.

Many thanks for the examples. I now know why my code failed. I was not aware that the event was called change for item selection I was trying to use propertychange and in the case of the password configuration I forgot to include the all-important keyword set.

Thanks also for fixing the button problem in groups created with mergeTBObjects in the latest Powerpac. I have always had to use TB fields with Raised border style and custom functions triggered by user properties mousedown and mouseup to move the fields 2 px right and left making them more button-like. When I have time I'll go back and simplify all this.

John