Fog Creek Software
Discussion Board




Asynchronous processing in VB

I have some VB code that is supposed to receive RS232 messages and process them.
The code is localised in an OCX.
Whenever it receives a message it raises an event.

Some other code uses the OCX to process the events.
I was, apparently mistakenly, under the impression that events where placed on some sort of queue and picked up by the receiver(s) whenever a new event arrived.

But it turns out that during the time that one event is being processed, the code that originally raised the event does not proceed. It seems like one big chain of function calls, which might explain why new events do not get raised.

This is where my problem starts, because the code that receives RS232 messages must also reply to the transmitter. And it does not do so until the raiseevent returns. Which violates the RS232 based protocol.

I have tried decoupling by putting everything received from RS232 on a local queue and activating a timer to initiate further processing, hoping the timer and RS232 would be running asynchronously, but this does not appear to work either.

So I am stuck. Not being a real programmer -- I play one in the movies, or this project I am helping out on anyway -- I know too little about VB to do this, and have no means to use multithreading capabilities of other languages.
I understand multithreading well, theoretically, but my hands-on experience dates back 10 or so years, and to different platforms.

So, HELP!

Practical Geezer
Wednesday, May 14, 2003

Rather than raising a VB Event, it sounds like you need to raise some sort of aysnchronous event, either immediatly before or after responding to the RS232 signal.  Various mechanisms are availabe to do this - you could write the events to a database or post them onto a MSMQ (Microsoft Message Queue) queue.  You would then have a seperate process to process these queued messages seperate from the OCX.

Tommt
Wednesday, May 14, 2003

VB events (also known as connection points) ARE in fact function calls, not windows messages. As such, they are synchronous, as you've seen.

As far as fixing the problem goes - can you restructure your OCX so that it sends the ACK message before firing the event? How does the delay violate the protocol; is it just a timing requirement, or something else?

The ideal solution would be to put the serial comm stuff on a separate thread, but of course VB doesn't do that.

Chris Tavares
Wednesday, May 14, 2003

This is VB6 right? If my memory serves me correctly you could try doing the timer trickery with a *new instance* of another form (which doesn't need to be displayed).

' in the event that gets the RS232 notification...
Dim processForm as New ProcessForm()
processForm.Stuff = stuff
processsForm.StartAsync()

'Form ProcessForm...
Public Sub StartAsync()
  myTimer.Start()
  'returns to caller now...
End Sub

Sub myTime_Timer()
  'do stuff with Stuff...
End Sub

Duncan Smart
Wednesday, May 14, 2003

Practical Geezer,

Check out the Coffee examples on the VB CD. Otherwise, sign up for the VISBAS-L list - this issue has been covered in the archives many times:

http://peach.ease.lsoft.com/scripts/wa.exe?A0=visbas-l

Seeya

Matthew
Wednesday, May 14, 2003

Tommt,

Your advise is way over my head. Functionally I think I understand what you are trying to say, but not being an experienced developer I would get lost in the details.
But thanks anyway.

Chris said:
"As far as fixing the problem goes - can you restructure your OCX so that it sends the ACK message before firing the event? How does the delay violate the protocol; is it just a timing requirement, or something else?"

The ACK is not one specific ACK to the message just received.
The protocol is based on ISO 1745, which is a multidrop protocol that utilises a control station.
This basically means that a control station is constantly polling clients to see if they have something to send.
A poll must always be answered if only to say "no, nothing to send".
This polling is used by the security system that is our control station as a "is still alive" signal. Not replying raises an alarm.

Duncan said:
"This is VB6 right? If my memory serves me correctly you could try doing the timer trickery with a *new instance* of another form (which doesn't need to be displayed)."

Yes, VB6. I already tried a timer trick, but not with a new instance of another form. I am not sure this will work inside a VB-OCX, but I will surely give it a try, thanks.

Matthew,

Thanks, I will go and see immediately.

Practical Geezer
Thursday, May 15, 2003

*  Recent Topics

*  Fog Creek Home