Re: VB6 (formless) Timer class



Larry Serflaten wrote:

There is no need to re-invent the wheel. VB ships with a Timer control
for use on its forms. You can use a form and timer without having to
show the form to the user. Doing so will let you use familiar code to
handle your task.


The problem with this is that the "Event classes" become unnecessarily heavy (containing a form that has to be created, consumes resources, and is not seen), plus I want to minimise the number of ActiveX controls I use in my project. So if there is a way I can obtain the same functionality without using an ActiveX control, I prefer it.

What you need to be concerned about is the thread used to execute
your tasks. If you sit and wait for incoming calls, things will go smoothly,
until you start responding to those calls. If you send a class off to do
some 'asyncronous' task, then part of your application's processing has
to include the time necessary to do that task. If that task is processor
intensive, then it wil effect your ability to respond to incoming calls.

After launching some number of those intensive tasks all trying to run at
the same time, you will find you are no better off than if you'd responded
to the calls directly. That is because your entire program can only execute
*one line of code at a time*.

If execution is taking place in a CPU hogging routine, (no DoEvents) then all
other processing in your application grinds to a halt until that routine has ended.
That includes the code you want responding to incoming calls.

Since you can only execute one line of code at a time, tasks (routines) that
have no DoEvents are going to run to completion, before any other task
you may have started. In essence you will have built a queue where the first
tasks in run to completion, ahead of any other task created.

If the 'queue' response is acceptable to you, why not build it as a queue,
(a bit simpler) instead of the not-so-asycnronous multiple tasks?


Yes, this sounds interesting, could you tell me more - could you clarify what you mean by "build it as a queue" ?

If the queue method is not acceptable, and you really want those tasks to
run asyncronously, then you need to give them their own thread, their own
process, in which to complete their task. Again, you need not re-invent the
wheel, VB's ActiveX exe projects run their own process and can be created
and controlled from your VB application.

So, in a nutshell, what is it you really want to do?

Actually threading etc are red herrings - my main objective is to be able to handle large numbers of data coming in via WM_COPYDATA messages - WITHOUT dropping one. I remember reading somewhere, that windows messages remain on the message queue - either until they are read off the queue by the application OR until they timeout (IIRC, the timeout is specified in the SendMessage function call - but I'm sure someone will correct me if I am wrong). However, I read a thread a little while ago, where someone had asked the question as to whether messages sent by WM_COPYDATA are guaranteed to be read of the queue by the application - and IIRC, someone replied to say that if the application is busy (for example, waiting for user import etc), then all bets are off, and the messages will just "fall off" .... this is what I'm trying to prevent .... if messages can "fall off", then I need to find a way of preventing that, thats what I'm trying to do in a nutshell.

LFS



.

Relevant Pages

  • Re: VB6 (formless) Timer class
    ... What you need to be concerned about is the thread used to execute ... other processing in your application grinds to a halt until that routine has ended. ... That includes the code you want responding to incoming calls. ... If the 'queue' response is acceptable to you, why not build it as a queue, ...
    (microsoft.public.vb.general.discussion)
  • Re: Lahman, how ya doing?
    ... >> of events held by Timer. ... >> to make a copy for the queue, and destroy the copy at the end. ... I might send the same event to multiple objects on a tick, ... >software must already support a means for the responding action to ...
    (comp.object)
  • Re: why UI gets hangs
    ... Note that posting too many messages to the queue will delay WM_TIMER and WM_PAINT ... if it has not processed messages for some time it puts Not Responding ...
    (microsoft.public.vc.mfc)
  • Re: GC performance - GC fragility
    ... Server not responding. ... Then a few hundred users will busily start requesting refreshes, ... will all queue up for processing when the stall is done, ...
    (borland.public.delphi.non-technical)
  • Re: Single producer, "one-shot" work queue implementation, no lock on queue.
    ... usec for just calling execute() directly). ... overhead that's closer to 5nsec than 5usec. ... where there's only a single item in the queue. ... virtual void Execute() = 0; ...
    (comp.programming.threads)
Loading