Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VB6 - Timer Delay-failure to halt application 1

Status
Not open for further replies.

hafod

Technical User
Mar 14, 2005
73
GB
Hi
Can you help with the following timer code. I am using it to introduce a delay in my USB interface application which makes write 'calls' to a hardware USB digital/analogue interface via a DLL (supplied with the hardware. The code will introduce delays (i will need to experiment here) between successive interface 'Read', 'Clear' and 'write' operations.

Problem is that when I call the wait function, the application features can still be used, within and despite a wait call of many seconds (say 5000 mS) which is the numeric value I would pass to the function (ie no delay at all!) My understanding of 'doevents' is that it prevents any activity in the VB application, but allows the Win OS to process other application tasks in the background. The latter clearly happens as there is no 'lock up'.

The wait function code is given below. I pass values in milliseconds dwduration).

Many thanks in anticipation of you help.
i suspect the solution will be obvious when presented!

Hafod
Code:
private sub Wait(dwDuration) as long
Dim dblstart As double, dblEnd As double
dblstart = timer
dblend=timer + (dwduration/1000)
Do
   dblnow = timer
   DoEvents
Loop Until dblNow< dblstart Or dblnow>dblEnd
End Sub
 
Doevents doesn't prevent activity in the VB application ... quite the opposite in fact. It allows the application to process other events that have been stacked in the event queue. If you really want the application to pause for some specified number of milliseconds then look at the Sleep API
Code:
[COLOR=black cyan]' In a Module[/color]
Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)


Private Sub Wait(dwDuration as Long)
Sleep dwDuration
End Sub
 
Hi Golom,
Many thanks for your response. I implemented your code suggestion and appears to work well with the limited delays I have tried so far. So a big thank you!

Incidentally, can you advise me how the code works. It appears you are making a call directly to the OS 'core' itself? I havent delved into this (risky) area before!! Also,would you expect the 'egg timer' on screen during the WAIT subroutine call?

The delay appears to eliminate process timing problems which occur when the 3rd party DLL instructs the hardware via the usb port. At present, it merely sends an alternating '10101010' test pattern to the hardware which subsequently displays the test data using LED's. (0.5sec alternating sequence)

Look forward to your response.

Again, many thanks,
Hafod

In context the code (pseudo) is used as follws:
Code:
.....
WriteAlldigital(decimal value1 0-255  - 8bits)
wait (500)
WriteAlldigital(decimal value2 0-255  - 8bits)
wait (500)

etc..
[\code]
 
The "egg timer" (AKA the HourGlass mouse pointer) is something that you make happen with either
Code:
Screen.MousePointer = vbHourglass
[COLOR=black cyan]' Some processing code[/color]
Screen.MousePointer = vbDefault
which displays the hourglass pointer everywhere on the screen, or
Code:
Me.MousePointer = vbHourglass
[COLOR=black cyan]' Some processing code[/color]
Me.MousePointer = vbDefault
which displays it only on a specific form (referenced with "Me").

How it works?

The Sleep API is just a call to a system routine that, from the perspective of your app, just goes away and doesn't return control to your app until the specified amount of time has elapsed. It doesn't disable any other process running on your system ... just the one that calls it.
 
Hi Golum,
Thanks for your last response - that was helpful and informative. Incidentally, using your code I have established minimum delay for USB comms to the interface is 20mS - so a big thanks (so 50-100 is an established reliable figure now).

Can I ask what advantage when using a VB intrinsic Timer object has (not in the context of my USB application) when introducing delays in programs. For example, when using say a 'splash screen' at program start -up, your solution appears a more elegant (and perhaps more accurate) approach? Are timers (vb objects) more appropriate for executing code at pre defined intervals? Under what circumstances would you use a timer object?

look forward to opinion here.

Kind regards,
Mike (Hafod)
 
I wouldn't use a program delay (i.e. a timer) for a splash screen. The basic reason is that I don't know how long it will take to accomplish the tasks that the are happening while the splash screen is visible. If I use a timer then I need to guess what timer interval to use. I prefer to program such things with something like
Code:
Sub Main()

frmSplash.Show

[COLOR=black cyan]' System Initialize Activities[/color]

frmMain.Show
frmMain.ZOrder 0
frmSplash.Unload

End Sub
In that way the splash screen disappears when it's no longer needed and there's no need to be concerned with how long it will take (i.e. a timer). The SLEEP API wouldn't be appropriate for this since it suspends ALL activity in the app. In contrast, the intrinsic timers in VB allow processing to continue during the timing process and only interrupt that processing to run the code within them at some predefined intervals.

Others may (probably do) have creative uses for timers but my own approach is that I use timers only in relation to external processes (e.g. monitoring a folder to see if a new file has been created by some other process.) Internally (i.e. for things that happen within my app) I generally build classes that raise events and then use the event handlers to do what's needed. Within my own code I generally have the knowledge about when a specific process has completed and don't need to invoke a timer to continually test for that condition.
 
Hi golum,
very helpful expert comments and opinions and these will help me to develop my own VB app. programming skills, particularly with regard to delays and interrupts.

maybe we'll meet on the furum again as I encounter other challenges I cannot fully resolve.

Again, many thanks for your help.
Hafod

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top