Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
MsComm control problem
Message
 
 
À
30/07/2002 16:33:36
Information générale
Forum:
Visual FoxPro
Catégorie:
Contrôles ActiveX en VFP
Divers
Thread ID:
00684163
Message ID:
00684212
Vues:
17
Thanks for the quick response..

Actually, I have changed the sthreshold to various points....right now it's sitting at 1 character. I've had it up to 512 - all with the same results.

There is only one cable involved, and the port is open from beginning of program to end as it intercepts received info from the scale as well as sending info to it for internal processing. The scale appears to be taking it's time processing what's coming in, but my understanding of handshaking leads me to believe that the Fox program should wait.

One other question: if I use the mscomm1.output to add information to the buffer before the buffer is empty, will that overwrite the buffer or append it to the end?

Last thought: I suspended my program just after the mscomm1.output = string command and saw in my debug window that the outbuffercount was 57. It sat there (as there was nothing attached to my port at the time) until I typed the following at the commandline:
l_count = mscomm1.outbuffercount
This command changed my debug property to 0!


Most frustrating!



>Hi Steve,
>
>>I determined that I had a timer running which was actually checking the inbuffercount and placing a message on the screen if not zero. However, this appears to reset the buffers. Setting a trace on the outbuffercount appears to reset the buffer as well. Unfortunately, I have found no way to see if the data is staying in the output buffer or is being reset because checking the buffer size appears to clear it.
>>
>
>Interesting observation. You might try increasing your .SThreshold value so you aren't hitting that event so heavily. Also, how much processing are you doing there? A DOEVENTS might be in order...
>
>>In addition, the oncomm event appears to be firing after some interval with the status of "1" when there is no connection to the scale and handshaking is on. My impression (or misguided wish) is that the oncomm should fire either after a send or change in status is detected. Otherwise, it should wait, buffer ready, until something is ready at the other end.
>>
>
>Are you reading muliple scales, manually disconnecting or switching cables?
Steve Howie, owner
DaSH Technology
Denver, CO
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform