Creating a Delay in VB6

[R3PooC]

Hello,

Im new to programming and am finding it difficult to find a fuction in VB6 that will enable me to delay or wait for a time before continuing the program.

For example- I am outputting a string through a serial port and want a 'Delay' before i output the second string, as below.

SerialCom1.PortOpen = True

SerialCom1.Output = StringA
''Delay here (2000 milliseconds)
SerialCom1.Output = StringB

SerialCom1.PortOpen = False

Can anyone help?
thanks in adavnce.

R3PooC

 

[vbSun]

Sleep(milliseconds as long) is the way to go.

Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

2 seconds does not seem to be a lot of time, but if you can break 2 seconds in to smaller time periods, you can make sure that the application does not go in to the 'not responding' state.

 

[Nimroduk]

Sleep suspends the process. I don't know if using it in conjunction with a comms control (in process?) would interfer with the transmission/receipt of data ?

I would be tempted to use a loop:

Dim ldTime As Double

ldTime = Timer
While Timer < (ldTime + 2)
    DoEvents
Wend

 

[HyperEngineer]

Another way to do it is the use of GetTickCount API. This will allow you to have millisecond delays.

In a module in the Declarations section:

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

In the you code:

Dim lStart As Long

lStart = GetTickCount
Do
  DoEvents
Loop Until (GetTickCount > (lStart + 2000))

The Timer returns the number of seconds since Midnight. The GetTickCount returns the number of milliseconds since the last reboot. If you have long time delays, you may have a problem if your program works through midnight. With GetTickCount, you just have to make sure you reboot before 47 days have past.

It doesn't appear, for this case, to make a difference which one you use. But maybe for future programming you may want the alternative.

HyperEngineer
If it ain't broke, it probably needs improvement.

 

[strongm]

>This will allow you to have millisecond delays

Not quite ...

 

[BobRodes]

From Microsoft:

The resolution is limited to the resolution of the system timer. [...] If you need a higher resolution timer, use a multimedia timer or a high-resolution timer.

I knew I'd seen something from strongm on this. After wandering around numerous unrelated places, including 13000 feet up in the Andes, I found it in here: thread222-1335999.

Bob

 

[SBerthold]

If anyone is interested:

http://support.microsoft.com/kb/172338/en-us

 

[strongm]

I should point out that that article is wrong with reference to the various timer resolutions, specifically for GetTickCount and timeGetTime.

GetTickCount is limited to the system timer resolution, and this varies between 10 and 25 ms on different Windows platforms (for example it is 15.625ms on the XP SP2 box I am currently using, but 10.0144ms on one of the old W2K boxes)

And the resolution of timeGetTime is also limited to the system timer initially, but the user can actually select the resolution of down to 1 ms using the timeBeginPeriod API call

 

[SBerthold]

>varies between 10 and 25 ms on different Windows platforms

I think they were just stating the basic (approx.) minimum, as seen by their test results. Other MS pages also mention the differences between OSs.

The code should show what a specific system returns.

 

[dilettante]

Academic really. Using the MSComm control as a pseudo-synchronous object has limitations you've already run into.

Async operation would be the way to go here, using OnComm events where CommEvent = comEvSend to prompt you for the next send. Of course you'd need to rewrite your sequential conversation script as a simple state machine.

 

[tedsmith]

Routines that use loops require the computer to repeatedly execute code and often slow down the machine for the period of the delay.
Putting the doevents in the loop allows other things to happen but I have seen many posts saying the use of DOEVENTS can be dangerous. You never know what it is going to do to another interrupt driven routine that might happen in the middle of the delay (like the reception of data on another port or a keystroke triggering something else).
I would go with dilettante's suggestion if you can - much more reliable in the end.

It may be that you can't get as response from the receiving device (like a dumb machine) and a delay is needed anyway so I would use the Timer control. Just set it to the delay required (1000=1second) and enable the control when you send the first data and have the Sub OnTimer send the next or subsequent one and disable the timer or re-enable it if there is more data to follow.

Although some people pour scorn on the old Timer control, I still find it useful for simple delays as it is operating at a deeper level and doesn't seem to affect or be influenced much by other events. It is apparently not good to have more than one timer running at once. If I want different time delays at the same time, I use one timer that is ticking away continuously every 100ms to show the time of day every 10 pulses (once a second) and use it to count up variables to various limits to give the effect of a timer with a resolution of one tenth of a second. Eg. for a flashing light I count up and reset a variable 5 pulses to give a flash of half a second using the one timer control for everything.

(No doubt strongm will disagree with me!)

 

[strongm]

>No doubt strongm will disagree with me!



But I won't. Certainly the Timer control has its place, and using it this way works well.

 

[tedsmith]

Hi strongm!
Remember that long torturous thread222-1335999: How do I convert a BMP to JPG stream (not a file)? It started about converting a bmp to a jpg in code but wandered off into the subjects of timer accuracy and network pic downloading?
Well I gave up temporarily on the original problem because when I tried to use the GDI+ libraries on your example, I got conflicting results and different errors. In your example,
GDI+ Type Library 1.31 (6/2/2003) gives "Sub or function not found" on the statement
Set myStream = CreateStreamOnHGlobal(b(0), True)
whereas,
GDI+ Type Library 1.05 (11/9/2003) gives "Cant find project or library" on the line
Private Function GetEncoderCLSID(ByVal strMimeType As String, outCLSID As CLSID) As Long
What did I do wrong?
I tried various manipulations of the CreateStreamOnHGlobal without success.
Any help you can give would be appreciated.

By the way I found an excellent "Winsox" with the OCX written in VB that beats the Microsoft Winsock hands down. The OCX code is published and you can extract the API routines you want from it to make it even simplier.

It's Dataarrival fires AFTER the last bit has been received eliminating the winsock large file problem and it only needs the one server control to handle multiple clients, automatically creating extra sockets as more clients call in (I tried 500 sockets & they all work simultaneously without any problems)It can be found at:-

http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=35239&lngWId=1

other versions and a version written in c++ on links on that page
I would value your comments if you can see any pitfalls with this.
Ted

 

[strongm]

This is slightly hijacking this thread - but in quick response: I use GDI+ 1.31, and the code as given in that thread works fine on my PC. Certainly you'll get the error you mention for version 1.05, but I'm afraid I can't suggest why you get the problem you describe for 1.31 - unless there is a problem with your references. I'd suggest that you start a new thread if you want to discuss this further.

 

[tedsmith]

Thanks,
Yes I would have thought there should not be an error but I notice some other examples use a different syntax for CreateStreamOnHGlobal as though it was a DLL and not a reference TLB. Maybe I have something else opened in references that is conflicting with it?
I will start another thread.