wait?

Hi,

Is there any solution to make visual basic code wait for previous line to be done before going to the next?
I am not really familiar with visual basic but I am working on some program which should run in real time so it really need stuff to be done in the right order.

Any hint would be helpful!
Thanks,
Saska

What you want is what happens anyway, apart from a few rare special cases.

If there is a particular situation that is causing a problem for you, show us the code - because even if it is what you think, how it needs to be solved depends on the code.

Hello

I am using shell function which is asynchronous and I suppose that's the reason for all mess, there's a lot of piping and similar, so everything mixed gives me the fact that some parts are done when they should, some of them aren't. I am not sure if I can share code with you at the moment, but I've found one solution on the web, and it would be great if I can hear your comment. The only problem is that I don't know how much time I should wait...

Code:

---

Public Declare Function GetTickCount Lib "kernel32" () As Long

Public Sub wait(ByVal dblMilliseconds As Double)
    Dim dblStart As Double
    Dim dblEnd As Double
    Dim dblTickCount As Double
   
    dblTickCount = GetTickCount()
    dblStart = GetTickCount()
    dblEnd = GetTickCount + dblMilliseconds
   
    Do
    DoEvents
    dblTickCount = GetTickCount()
    Loop Until dblTickCount > dblEnd Or dblTickCount < dblStart
     
End Sub

---

By the way I've said that I am not so familiar with vb, which doesn't mean I am not familiar with programming :)

Search this forum for ShellAndWait. It is a routine wrapped around the ShellExecute API and will do what I think you are asking for.

May I suggest using the SecondsToWait sub? I believe it was written by a Microsoft MVP.

Here's the code: http://www.xtremevbtalk.com/showpost...92&postcount=3

Use it like:

Code:

---

Debug.Print "Before wait: " & Second(Now)
SecondsToWait 3
Debug.Print "After wait: " & Second(Now)

---

Waiting around for asynchronous events is not always a good idea since you come upon the problem you have described - How long do I wait for?. The fact you are using Pipes indicates that you're talking about Program-to-Program communication (?) where, perhaps, an event in Program A needs to be communicated to Program B whilst Program A continues to run etc. Since VB6 doesn't support multiple threading it's difficult to use asynchronous I/O completion routines to trigger an interrupt when a Pipe I/O completes.

Polling is an option, where, for example, Program B 'plants' some data into, say, a control (eg a TextBox) in Program A and Program A checks the control every xxmS to see if anything has arrived. Under those conditions, the interval is not important since if you just miss it on Poll x you'll get it on Poll x+1, (as long as Program B hasn't changed it during the 'pause'. If that's likely then you'd have to introduce some sort of protocol where for example, Program A clears the control, and before Program B 'plants' anything it checks that the control is empty, if it isn't then it has to Poll until it is. Can get a bit messy if there's more than one 'client'. Of course, Program A is using resources when it polls and there's nothing there. If the polling is controlled through a Timer, then Program A can be processing away merrily until something from Program B arrives, process the data and then carry on doing whatever it was before the timer interrupt.

This may be far too late but, if you have source control of the Programs involved, you might consider using Winsock rather than pipes to provide the IPC. (There are other ways but that's my personal preference) It works asynchronously, is bi-directional and supports multiple simultaneous 'clients' on the same or different machines. There'd probably be less design changes required - instead of issuing a Write to a Pipe, you'd be issuing a Winsock.SendData which would cause a Winsock_DataArrival event in the receiving program which could then buffer and process the received data. The only additions perhaps would be the introduction of a protocol, and buffering in the receiver so that it knows when the complete record has arrived.

Just a thought