I'm at it again.
I still see a problem with a look-up in a pop-up from a form.
After the look-up is complete, the session values for the primary table are cleared. This causes errors in later processing because the page depends on the session values to be stable. From the NetTalk book you can see that session values are to be depended on -
- "... it’s important again to use session values rather than local variables most of the time."
- "2. In the Web it’s appropriate to use Session Values in Filters, not Variable values. "
- "Remember the form is session value based, so the hide condition needs to use session values, not regular field values."
The attached example should show what is happening. or you can just go here -
http://tinyurl.com/7h9n7reHere is what to do to see the effect.
Open the website - it will display a list of invoices.
Click the shopping cart to add a line item to that invoice. - the update invoices page will be displayed (as an insert to the line items table)
You should see the 2 tabs. the top is the line item entry form usual fields - invoice id, item id price, quantity, and total
The bottom shows display fields of the session values for those line item fields. - Make a change in the item and the session values reflect what happens.
Now enter an item id - type in a 1, 2 or 3 -
don't select from the look-up yet.
Hit tab and you will see how everything is updated.
Tab down and change the quantity. You will see your change and the total display
Try that a couple of times - works nice.
Now click the look-up button and select an item.
Tab down and change the quantity.
What happened to the Product, Price and Total?
Note - Sometimes the product id will be cleared before you get to tab down to the quantity. That is part of the same problem, but is inconsistent due to the nature of how threads get timed.
If you load the attached example, compile and run it on your own machine, start up DebugView and watch as you make the selection. You will see something similar to this -
The (#:#) shows the Session Id and thread number -
[20824] [netTrace][thread=3] (0:3)_Open.
[20824] [netTrace][thread=4] (0:4)_Open.
[20824] [netTrace][thread=3] (170104446:3)_UpdateLineItems START Stage =-Div
[20824] [netTrace][thread=5] (0:5)_Open.
[20824] [netTrace][thread=4] (170104446:4)_Close.
[20824] [netTrace][thread=3] (170104446:3)_FileToSessionQ:PRODUCT
[20824] [netTrace][thread=3] (170104446:3)_After Lookup gsv Pro:RRP=399
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems START Stage =-SetPics
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems START Stage =-InsertRecord-Init
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems START Stage =-SetPics
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems START Stage =-InsertRecord-StagePre
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems PreInsert
[20824] [netTrace][thread=5] (170104446:5)_FileToSessionQ:C:\Documents and Settings\All Users\Documents\SoftVelocity\Clarion8\Accessory\Capesoft\NetTalk\Web Server\ParentChildBrowse (25)\LINEITEM.TPS
[20824] [netTrace][thread=5] (170104446:5)_UpdateLineItems START Stage =-FocusBack
[20824] [netTrace][thread=5] (170104446:5)_Close.
[20824] [netTrace][thread=3] (170104446:3)_Close.
In here you can see that Thread 3 is still processing the code after the lookup when thread 5 starts to refresh the page. Unfortunately, thread 5 continues and acts as though the insert just started so it does a call to PreInsert which, doing its good housekeeping, clears the session values in the call to FileToQueue.
Thread 5 closes, and thread 3 closes never knowing what just happened.
BTW - the same thing happens in NT 5 with just one exception - Thread 5 does not call PreInsert; it only calls the INIT to refresh the page.
I am interested in hearing from anyone having odd things happen after a lookup or actually NOT having this issue. Maybe it's me.
The attached example is taken from Example#25 ParentChildBrowse.
Set your port number in the INI file. g:PortNumber=88
I added embeds to watch and count threads as they are opened and closed and added those IDs to the trace outputs.
TIA
Chris C
[attachment deleted by admin]