Problem other-button firing wrong Row ID field

[Nick]

Hi,

Consider this situation:
The first row in a (netwebbrowse) table is selected (higlighted) and now you click on an other-button on another row.
You do NOT select that other row first but you click directly on the other-button like most people would do.
The effect is that the row ID field of the first row is "passed" through to the procedure that the other-button calls and
a fraction of a second later the row id field of the other-button's row (the right id field, the one you want).

Do you follow me?
I guess what is happening is that the other button fires before the row where it is on is selected and when that
row is selected it fires again. Although it seems like this is happening.

The "include the row id field" setting is of course switch on.

What I want is to send an email and I want to put the email-adddress of the selected customer in the loc:To field of
the EmailFormControl.
So at the start of the EmailFormControl-procedure I pick up the id field with the p_web.GSV() method and read the customer-record
and with the p_web.SSV() I put this in the loc:To.
That works fine but shows the wrong data (only) in the above situation.

I've put a stop() in it that shows that the wrong id field comes in first and after that the right one.
If I leave the stop in the right data appears, probably a timing matter.
If I have no stop there the wrong data is fetched due to the wrong id field (in the above situation).

I checked the standard button for changing and that doesn't show this behaviour.

What's going on here?   Is it the browse-other-button or should I fetch the row id field in the
EmailFormControl at another point?

TIA,
Nick

[Nick]

If I put a pause of 1/10 sec instead of the stop this problem is gone.

Nick

[Bruce]

>> You do NOT select that other row first but you click directly on the other-button like most people would do.

indeed, this is expected.

>> The effect is that the row ID field of the first row is "passed" through to the procedure that the other-button calls

no, this is inaccurate. Assuming you have the "Include Row ID" option for the button on, then the RowID for _that row_ will be passed to the receiver. but _only_ the ID field, not the contents of the whole row.
The form _cannot_ rely on any code you've added to the _browse_.

>> and a fraction of a second later the row id field of the other-button's row (the right id field, the one you want).

At the "same time" a second request is passed from the browser to the server, this gets processed on a separate thread, and informs the browse of the new row selected. Clearly the "button procedure" cannot rely on this as it happens asynchronously.

>> I guess what is happening is that the other button fires before the row where it is on is selected and when that
row is selected it fires again.

there are 2 requests - completely separate requests though. One fores to the button procedure, the other to the browse procedure.

>> If I put a pause of 1/10 sec instead of the stop this problem is gone.

this is a very (very) bad solution because it relies on the one thread completing before the other thread does what it needs to do. It will be highly timing dependant, and will vary from one machine, and one time of day to another. The correct solution is to get the correct rowid in the email procedure.

cheers
Bruce

[Nick]

>no, this is inaccurate. Assuming you have the "Include Row ID" option for the button on, then the RowID for _that row_ will be passed to the receiver. >but _only_ the ID field, not the contents of the whole row.
>The form _cannot_ rely on any code you've added to the _browse_.

Yes, I know that!
I don't rely on any other contents of the row except for the row ID field.
That's the whole point here, I get the ID field with p_web.GSV('ID Field') in the start of the form
and read the record based on that ID field value.


>this is a very (very) bad solution because it relies on the one thread completing before the other thread does what it needs to do. It will be highly >timing dependant, and will vary from one machine, and one time of day to another. The correct solution is to get the correct rowid in the email >procedure.

I know that too. It's not a solution but just to show you what is happening.

Please tell me how to do it.
I've included the row ID field, I click on the other-button and I pick up the row ID field with p_web.GSV().
The row ID field is the one component (long) of the unique key. The include row ID field checkbox for that button is on.
What's missing here? You say it can't be but I'm seeing it here...

Thanks,
Nick

[Bruce]

what NetTalk build are you on?

cheers
Bruce

[Nick]

Version 7.28

Hm, could it be that I read the row id field with p_web.GSV(...) just a bit earlier than that it is set so that I read
in fact the old value first?
If I do this wrong then how can I read just a fraction of a sec. later the right id field value? That could not be possible I guess.

Cheers,
Nick

[Bruce]

update to 7.34 - I think you're just struggling with an old bug.

>> Hm, could it be that I read the row id field with p_web.GSV(...) just a bit earlier than that it is set so that I read
in fact the old value first?

no.

cheers
Bruce

[Nick]

Ok will do that.

Thanks,
Nick

[Nick]

Yes that's it!

Thanks,
Nick