Forums

by CarlRanson >> Mon, 6 Jan 2003 5:40:12 GMT

Discovered an issue with Jade thin client today that might be relevant to some of you.

We have a control that makes some subbordinate controls at run time (eg, in windowCreated). As part of the process it sets the tab order of the new controls to self.tabIndex +1,2....etc.

A problem can arrise if there is already a control on the form with the next tab index. Jade will renumber the tab index of the subsequent controls the same way it does in painter. This can cause multiple tab indicies to be updated due to the newly created control, which all then have to be sent back to the app server.

The net result is you get a bunch of controls with different tab indexes to those set in painter, which all chew up traffic on the network.

This can be quite easily seen in the log file. You end up with something like this:
15:55:38 time=0 << #=1 Received (len=134) MyForm.createControl 15:55:38 time=0 >> #=2 Send (len=19) Notify property change: textbox.hwnd
15:55:38 time=0 << #=1 Received (len=10) textbox.maxLength 15:55:38 time=0 << #=1 Received (len=6) textbox.borderStyle 15:55:38 time=0 << #=1 Received (len=13) dteDOB.tabIndex 15:55:38 time=0 << #=1 Received (len=13) cmbRole.tabIndex 15:55:38 time=0 << #=1 Received (len=13) cmbOrganisation.tabIndex
15:55:38 time=0 << #=1 Received (len=13) txtStreetAddress.tabIndex
15:55:38 time=0 << #=1 Received (len=13) cmbDistrict.tabIndex 15:55:38 time=0 << #=1 Received (len=13) cmbCountry.tabIndex 15:55:38 time=0 << #=1 Received (len=13) txtPostCode.tabIndex

The first 4 lines are the new control being created in code, subsequent lines are JADE nudging the tab indexes along to fit the new control in, at a cost of 13 bytes of network traffic each. Bearing in mind that this can happen every time the form is created, for most of the controls on the form (if sequentially numbered) and at every client and it can add up to a lot of traffic.

The solution, of course, is to leave holes in the tab order numbering when you have controls that you know are going to allocate new controls.

CR

by allistar >> Mon, 6 Jan 2003 7:20:31 GMT

Hi Carl,
Thanks for the tip. I was aware that setting the tab index in code has issues, but didn't know it would cost multiple trips to the client, I'll have to keep that in mind with our custom controls.

Having to leave holes in the atabg index in the painter is a pain, it would be nice if there was some way of doing this automatically.

(Actually, I suppose you could iterate through every control on a form, find the persistent control for it and set the tabIndex to tabIndex * 10. You would then need to open the form in the painter and save it again. That should space the tab indices out enough.

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz ------------------------------------------------------------------

by torrie >> Mon, 6 Jan 2003 9:16:46 GMT

We have approached this in a slightly different way. Our custom controls create their child controls (where possible) in the painter and then use the flagControlForSave method on the form to make sure that this control is saved. The master control stores the names of its children and just relinks the references at run time. This allows the tab order etc to be fixed at design time as well as limiting the traffic at run time as the control does not need to be created in code. There are several method on the control classes (isMoveable, isSizeable, canBeChildOf etc) that can be used to stop form designers from moving or changing the parent of a control.

Torrie

by torrie >> Mon, 6 Jan 2003 9:16:49 GMT

We have approached this in a slightly different way. Our custom controls create their child controls (where possible) in the painter and then use the flagControlForSave method on the form to make sure that this control is saved. The master control stores the names of its children and just relinks the references at run time. This allows the tab order etc to be fixed at design time as well as limiting the traffic at run time as the control does not need to be created in code. There are several method on the control classes (isMoveable, isSizeable, canBeChildOf etc) that can be used to stop form designers from moving or changing the parent of a control.

Torrie

by CarlRanson >> Tue, 7 Jan 2003 0:38:28 GMT

Just one minor correction here. In the data ive seen there were NO extra round trips to the server as all the changes in thin client are cached until they absolutly have to be transmitted. But when the transmission finally happended there was extra data.

So its not that it introduced a problem with lantency, just bandwidth wastage.
Just wanted to clarify that.
CR