Hey,
OK, since everyone that works at RS (or used to) is so certain that
there's no re-entry unless it's an Error, I'll not keep questioning
that for now unless I can prove it.
[snip]
The latest test case (v2.0) makes it very clear that overlapping occurs
even without threads or the error event being fired.
[jycozgss]
http://support.realsoftware.com/feedback/viewreport.php?reportid=jycozgss
1. Run the test case.
2. Overlapping occurs frequently.
3. Quit.
4. In the DataAvailable event, uncomment "#pragma BackgroundTasks False"
5. Run the test case again.
6. Overlapping no longer occurs.
Yep, I can entirely confirm this. Plus, I've altered your test case to
make it very obvious, here's how:
1. Add a boolean property to the main window called 'busy'
2. Modify the DataAvailable event in Receiver so that it looks like:
if busy then break
busy = true
<original body of DataAvailable Event>
busy = false
Now, when you run the example in the debugger and get an overlap
execution stops at the break and you can examine the stack. It's clear
there is two calls to DataAvailable overlapping. The first event is
interrupted right at the start of the While loop for me.
I think this is pretty conclusive evidence, yes?
Unless the fact that you've got these sockets as controls makes any
difference...??
Thanks ForRBasic for the test case. (I think I remember talking with
you way back when I was first demoing RB 5.5.5).
jp
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
