Two Nettalk Interactive issues and example

[Rob Kolanko]

Hi Bruce,
I have attached an example program to show two Net talk issues. This is a modified version of a browse that I using as popup lookup for an item in a tree structure. The tree structure is irrelevant to the issues, it was just easier to extract and modify this procedure into an example program to demonstrate the issues.

• Issue 1. When a button in a form is refreshed from an event from the embedded browse procedure ( or any event in the CallDiv routine ) the button is no longer active. In the example, on the popup lookup for a department is displayed, press a Level Down button on one of the rows to display next level down. The Level Up button will appear on the form, but it  does not work or generate any events. If you comment out the Do Refresh::Drillup line in the CallDiv embed and remove the hide condition on the button, the button will  work.
• Issue2: When a button on a row of a browse is set to refresh the entire browse when  selected. After the browse is refreshed, the first row is shown to be selected, however the key field of the row has not been saved in the session variable which occurs when the row is clicked on. In the example, on the popup lookup for a department is displayed, press a Level Down button on one of the rows to refresh the browse to display next level down. You see that the first row is selected. Now press the select button on the form and you will see that the record id in the session variable is not the selected record, but the id from the record selected to refresh the browse is in the session variable.  
  

Thanks for looking into these issues for me.
Rob

[attachment deleted by admin]

[Bruce]

>> Issue 1.

because the button does not exist when the form is created (ie when it opens) events are not bound to the button at that point. The button is then added in later, but there's no call to re-bind the events to the new button. I've tweaked the 8.36 version (not released yet) so that the events are bound in this case.

Incidentally, you've added embed code to the CallDiv routine - this is unnecessary - you could (should) just add the DrillDown button and CurrentParent as items on the Reset List of DepartmentList. ie DepartmentList resets the other 2 on a change.

More on issue 2 in a moment.

cheers
Bruce
 

[Rob Kolanko]

Hi Bruce,
>>because the button does not exist when the form is created (ie when it opens) events are not bound to the button at that point. The button is then added in later, but there's no call to re-bind the events to the new button. I've tweaked the 8.36 version (not released yet) so that the events are bound in this case.<<

But when I tried to reproduce this issue in the web1 example, the button does work after the being hidden first. I have attached this example.  Edit any mailbox record,   Press the "Display counter" button and the "Counter ..." button will appear above. This counter button does function properly and it was hidden when the form was created like in the last example.  I am including this example such that it can be used to test the fix under this condition as well.

Thanks,
Rob

[attachment deleted by admin]

[Bruce]

hi Robert,

>> But when I tried to reproduce this issue in the web1 example, the button does work after the being hidden first.

yes. but in the web1 example you are hiding and hiding the button via another button on the same form. So the _Form_ is making the Ajax request, and processing the response, and part of that processing involves re-binding all the client side events in JavaScript.

In your first example it's a button on the _browse_ that makes the request, and hence it's the browse code that gets the response. The browse doesn't really "know" about the parent form (in the JavaScript that is) and so doesn't rebind the form's events. So in this sense the two examples you posted are quite different.

>> I am including this example such that it can be used to test the fix under this condition as well.

thanks - yes - the fix is "safe".

cheers
Bruce

[Bruce]

Issue 2

Internally this one is quote complex to understand, but boils down to the button being associated with a Row, which then completely repopulates the browse, which makes the setting "obsolete". But as the events bubble up to the form, the selected row setting bubbles up as well.

The most elegant way I've found to fix this is to add the following code to the DepartmentList procedure, to the Validate::Other2 routine (ie where your code is) and explicitly remove the row value there. In other words you're saying "yeah, that row value that got passed in, forget it...".

p_web.DeleteValue('RHI:REC_ID')

note that this is deleting from the ValueQueue, not the SessionValue queue, so the session value is unchanged. (and is being set correctly elsewhere.)

cheers
Bruce

[Rob Kolanko]

Hi Bruce,
The delete value method fixed the problem. Thanks that really helps.

As for the web1 example, I wanted to show that trying to make an example of issues is often difficult. I had a similar problem with another form where the user can press a button which will hide the button, a number of other fields including a browse and unhide another button on the same form. The un-hid button does not work, like in the initial example. I cannot reproduced the problem in an example program. I resolved the issue by setting the conditions and refreshing the entire form. Also since so many fields where changing, the page refresh is likely almost as efficient refreshing the individual fields. I am happy the way that this form is now working, so I have moved on.

Thanks again for your great support.
Rob.

[Bruce]

>> As for the web1 example, I wanted to show that trying to make an example of issues is often difficult.

yeah exactly. Imagine how hard it is for me when I don't even have access to the app causing the problem? Sometimes what you did is best - you strip down your app to show the effect. sometimes the "differences" can be very subtle.

cheers
Bruce