I've got a multi-column listbox with a bunch of data in it. One of
the columns contains "time" data. The other columns contain data
that are to be written to a serial control. I've got a timer that
constantly looks to see if its time to send the data of the next row,
based on the "time" column. When its time to send the data, I change
the list index of the listbox. This in turn, sends the data by a
bunch of serial.write calls in the listbox's change method.
All of this works... for fairly slow time intervals. If my data
needs to be sent very fast (.200 seconds between row times), I've
found that the program will periodically "lock up" for about 10
seconds and then resume. When I say "lock up", I mean that the user
interface does not respond at all during that period, including
button presses, menu selections, and movieplayer controls that are
playing temporarily stop.
My "fast" listbox row changes occur every .200 seconds. I'm sending
64 bytes of data for every row change, at 9600 baud. With the serial
port settings that I'm using, I should be able to send the 64 bytes
out of the serial port in .067 seconds. That should be plenty fast
enough to accomodate a data sends that need to occur every .200
seconds, I should think.
It doesn't seem consistent as to where the lock up occurs. If I make
a data set that has time data all .200 seconds from each other and
run the program several times, sometimes the lockup occurs very
quickly... within the first few seconds. Other times it might be 30
seconds into it.
If I comment out the line of code in the listbox's change event that
sends the data to the serial control, the lockup stops happening.
Also, with my serial connection unplugged, the lockup stops as well.
I've tried calling serial.xmitwait after my data sends, to make sure
that the data actually goes, rather than overflowing a buffer
somewhere. This does not seem to help.
I'm tempted to say that I'm overflowing my serial device's receive
buffer or something... BUT... this same code section works with the
same fast data set in an earlier version that is done in RB version
5.5.5.
Any ideas about what could be locking things up for 10 seconds? I've
been trying to fight this problem now for a couple of months, and I'm
still not sure what's going on here. I wish there was a way to know
what is happening during those 10 second periods!
Thanks,
Ron Benditt
Alien Apparatus Company, Inc.
http://www.alienapparatus.com
_______________________________________________
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>
