Thanks Lee,
We opened a support incident a while ago to help us get to the bottom of this problem with the first of our two applications. We supplied our source code and then after months of sending emails back and forth and making changes to our source code as advised, the problem still remained. The consultant even recompiled a new version of SCLIENT.EXE that contained some extra diagnostic information specifically to troubleshoot this problem - but no solution was forthcoming.
Eventually, you responded to one of my postings in this forum and informed me that the SessionBatchCommands() and SessionSendCommands() methods contain calls to DoEvents() which sounded to me like it might be the culprit. I removed all of these statements from our application, recompiled, re-deployed, and the problem went away for our first application. So, it wasn't our code, it was the SessionBatchCommands() and SessionSendCommands() statements.
I did the same to our second application, but the problem is still occurring.
The second application has some functionality in it where the user can scroll up and down a list by repeatedly pressing the F1/F2 keys. The effect of this design is that the user is pressing function keys in quick succession, causing the server application to process a lot more messages at a greater frequency than a simpler application where the user is just typing/scanning into input fields and pressing ENTER when they've finished.
I think this greater frequency of messages is highlighting a problem in the RFSDK that I'm guessing you don't hit with your RF Server and DMS RF products. Presumably because the user is typically scanning barcodes and typing quantities rather than repeatedly hitting a function key.
I can replicate the problem in the supplied RFSDKAsset sample VB application by changing the code in Form1.RFSApplication1_DataReceivedFromClient to this:
--
Private Sub RFSApplication1_DataReceivedFromClient(SessionData As String)
'increment call count
mlngCallCount = mlngCallCount + 1
If mlngCallCount > 1 Then 'If we're executing before the last call complete
MsgBox "Recursive!"
Else
Dim x As Long
For x = 1 To 500000
Next x
Monitor.Text = Monitor.Text & Me.RFSApplication1.RFSessionParseBuffer(1, SessionData) & "-" & Me.RFSApplication1.RFSessionParseBuffer(2, SessionData) & "-" & Me.RFSApplication1.RFSessionParseBuffer(3, SessionData) & vbNewLine
Call DisplayScreen(SessionData)
If CurrentScreen > 0 Then
Call DisplayScreen("")
End If
End If
mlngCallCount = mlngCallCount - 1 'Decrement call count
End Sub
--
And adding the following declaration at the top of the form:
--
Public mlngCallCount As Long
--
I found I had to put that loop in there on my machine to make sure that the application spends a bit of time in the procedure - as you would expect for a production application that has to make database calls etc.
Then start the app, start the windows client, connect and hold down the Esc and F1 keys. The application will flick back and forth between the main menu and the Track screen for a moment and you should then see the "Recursive!" message box pop up. An instance of DataReceivedFromClient() has started before the previous one has finished. Without the code in here to detect this, your client has just gone out of sync with the server.
I know this isn't a particularly "real-world" situation, but it proves that the capacity is still there in the RFSDK, and explains why our production RF Server occasionally logs these events and users get kicked off.
We could remove functionality from our application so they aren't pressing the F1/F2 keys so frequently, but obviously we'd prefer not to rewrite our application and take functionality away from the users without a concrete guarantee that this would solve the problem.
What I'd be curious to know is, does DoEvents() appear elsewhere inside the RFSDK - and if so, is it necessary?
Is the RFSDK 7.0 is available for download? I will be very interested to try this test against the new version.
Thanks,
Michael
