timeSetEvent 
Author Message
 timeSetEvent

I am calling the timeSetEvent function from an ActiveX EXE. It is called
from one of the functions of the exposed class. The timeSetEvent function
receives a function pointer, so I am passing it the address of a Sub in my
Utilities module. This is the call:
timerID = timeSetEvent(timerT, tC.wPeriodMin, _
                      AddressOf Utilities.viewTimerThreadFnc, 0,
TIME_PERIODIC)
The program crashes at this call. Unencouragingly enough, this problem does
not occur in Debug mode, when I have my test app linked to the .vbp, but
only when it is linked directly to the .exe.
The crash occurs because there is an apparent unauthorized memory access.
Does anybody have an idea s to what the problem may be?

Anthony



Wed, 12 May 2004 13:27:41 GMT  
 timeSetEvent
This is likely the well-known "TLS" issue.  The callback is occurring on
a separate thread, and VB6 does not properly initialize the Thread Local
Storage area (VB5 did, so this came as something of a surprise to many
people when they upgraded).

Try making your callback proc do absolutely nothing except return.  If
it works correctly then this is almost certainly the problem.

--

    Jim Mack
    MicroDexterity Inc
    www.microdexterity.com


Quote:
> I am calling the timeSetEvent function from an ActiveX EXE. It is
called
> from one of the functions of the exposed class. The timeSetEvent
function
> receives a function pointer, so I am passing it the address of a Sub
in my
> Utilities module. This is the call:
> timerID = timeSetEvent(timerT, tC.wPeriodMin, _
>                       AddressOf Utilities.viewTimerThreadFnc, 0,
> TIME_PERIODIC)
> The program crashes at this call. Unencouragingly enough, this problem
does
> not occur in Debug mode, when I have my test app linked to the .vbp,
but
> only when it is linked directly to the .exe.
> The crash occurs because there is an apparent unauthorized memory
access.
> Does anybody have an idea s to what the problem may be?



Fri, 14 May 2004 12:41:27 GMT  
 timeSetEvent
Hello Jim,

You are absolutely right. When I took all the statements out of my callback
it did not crash.
Now do you know how do I get around this problem?

Anthony


Quote:
> This is likely the well-known "TLS" issue.  The callback is occurring on
> a separate thread, and VB6 does not properly initialize the Thread Local
> Storage area (VB5 did, so this came as something of a surprise to many
> people when they upgraded).

> Try making your callback proc do absolutely nothing except return.  If
> it works correctly then this is almost certainly the problem.

> --

>     Jim Mack
>     MicroDexterity Inc
>     www.microdexterity.com



> > I am calling the timeSetEvent function from an ActiveX EXE. It is
> called
> > from one of the functions of the exposed class. The timeSetEvent
> function
> > receives a function pointer, so I am passing it the address of a Sub
> in my
> > Utilities module. This is the call:
> > timerID = timeSetEvent(timerT, tC.wPeriodMin, _
> >                       AddressOf Utilities.viewTimerThreadFnc, 0,
> > TIME_PERIODIC)
> > The program crashes at this call. Unencouragingly enough, this problem
> does
> > not occur in Debug mode, when I have my test app linked to the .vbp,
> but
> > only when it is linked directly to the .exe.
> > The crash occurs because there is an apparent unauthorized memory
> access.
> > Does anybody have an idea s to what the problem may be?



Sun, 16 May 2004 12:45:03 GMT  
 timeSetEvent
I have a problem calling the timeSetEvent function in my ActiveX EXE. It
requires a callback function, and somebody pointed out to me that the
problem might be the VB 6 TLS problem, and suggested I take out all my
statements out of the callback function to diagnoze. Apparently he was
absolutely right, because once I did that the program did not crash anymore.
So I know what the problem is, but not how do I get around it. I really do
need my timer to do something when it fires after all. Does anybody know how
to do this?

TIA

Anthony



Sun, 16 May 2004 12:50:32 GMT  
 timeSetEvent
I'd suggest that you look at the high-performance timer objects from the
CCRP, which don't suffer from this problem.  I used a CCRP timer in one
project and it worked (and continues to work) perfectly.
www.mvps.org/ccrp

I've also successfully used a timeSetTime callback by relying only on
module level global variables.  By that I mean that the timer callback
does only one thing: it increments a long integer (or perhaps sets a
boolean flag) which is declared Public in a standard module.

The main program runs in a tight loop in Sub Main, and checks each time
around for the change of state of this variable (resets it to False if
it's a flag).  When it pops, call a procedure containing the code you
would have placed in the callback proc.

This works better than it sounds.  I use it to drive a data acquisition
app which samples at 16 mSec intervals, and it works like a charm.

Yet another approach is to do nothing in the callback except post a
message to yourself -- use a message sink like Form_KeyUp that won't get
used otherwise, and run your callback code in that event.

--

    Jim Mack
    MicroDexterity Inc
    www.microdexterity.com


Quote:
> Hello Jim,

> You are absolutely right. When I took all the statements out of my
callback
> it did not crash.
> Now do you know how do I get around this problem?

> Anthony



> > This is likely the well-known "TLS" issue.  The callback is
occurring on
> > a separate thread, and VB6 does not properly initialize the Thread
Local
> > Storage area (VB5 did, so this came as something of a surprise to
many
> > people when they upgraded).

> > Try making your callback proc do absolutely nothing except return.
If
> > it works correctly then this is almost certainly the problem.

> > --

> >     Jim Mack
> >     MicroDexterity Inc
> >     www.microdexterity.com



> > > I am calling the timeSetEvent function from an ActiveX EXE. It is
> > called
> > > from one of the functions of the exposed class. The timeSetEvent
> > function
> > > receives a function pointer, so I am passing it the address of a
Sub
> > in my
> > > Utilities module. This is the call:
> > > timerID = timeSetEvent(timerT, tC.wPeriodMin, _
> > >                       AddressOf Utilities.viewTimerThreadFnc, 0,
> > > TIME_PERIODIC)
> > > The program crashes at this call. Unencouragingly enough, this
problem
> > does
> > > not occur in Debug mode, when I have my test app linked to the
.vbp,
> > but
> > > only when it is linked directly to the .exe.
> > > The crash occurs because there is an apparent unauthorized memory
> > access.
> > > Does anybody have an idea s to what the problem may be?



Sun, 16 May 2004 19:56:10 GMT  
 timeSetEvent
Hi Jim,

Thank you for the hints. I have one more quick question. For all of the
methods you mentioned (CCRP timer, global flag, raise an event), in which
thread does the processing of the timer event occur? I really need the
processing to be done in the timer thread, so the main thread is free to
receive more calls from the client app.

Anthony


Quote:
> I'd suggest that you look at the high-performance timer objects from the
> CCRP, which don't suffer from this problem.  I used a CCRP timer in one
> project and it worked (and continues to work) perfectly.
> www.mvps.org/ccrp

> I've also successfully used a timeSetTime callback by relying only on
> module level global variables.  By that I mean that the timer callback
> does only one thing: it increments a long integer (or perhaps sets a
> boolean flag) which is declared Public in a standard module.

> The main program runs in a tight loop in Sub Main, and checks each time
> around for the change of state of this variable (resets it to False if
> it's a flag).  When it pops, call a procedure containing the code you
> would have placed in the callback proc.

> This works better than it sounds.  I use it to drive a data acquisition
> app which samples at 16 mSec intervals, and it works like a charm.

> Yet another approach is to do nothing in the callback except post a
> message to yourself -- use a message sink like Form_KeyUp that won't get
> used otherwise, and run your callback code in that event.

> --

>     Jim Mack
>     MicroDexterity Inc
>     www.microdexterity.com



> > Hello Jim,

> > You are absolutely right. When I took all the statements out of my
> callback
> > it did not crash.
> > Now do you know how do I get around this problem?

> > Anthony



> > > This is likely the well-known "TLS" issue.  The callback is
> occurring on
> > > a separate thread, and VB6 does not properly initialize the Thread
> Local
> > > Storage area (VB5 did, so this came as something of a surprise to
> many
> > > people when they upgraded).

> > > Try making your callback proc do absolutely nothing except return.
> If
> > > it works correctly then this is almost certainly the problem.

> > > --

> > >     Jim Mack
> > >     MicroDexterity Inc
> > >     www.microdexterity.com



> > > > I am calling the timeSetEvent function from an ActiveX EXE. It is
> > > called
> > > > from one of the functions of the exposed class. The timeSetEvent
> > > function
> > > > receives a function pointer, so I am passing it the address of a
> Sub
> > > in my
> > > > Utilities module. This is the call:
> > > > timerID = timeSetEvent(timerT, tC.wPeriodMin, _
> > > >                       AddressOf Utilities.viewTimerThreadFnc, 0,
> > > > TIME_PERIODIC)
> > > > The program crashes at this call. Unencouragingly enough, this
> problem
> > > does
> > > > not occur in Debug mode, when I have my test app linked to the
> .vbp,
> > > but
> > > > only when it is linked directly to the .exe.
> > > > The crash occurs because there is an apparent unauthorized memory
> > > access.
> > > > Does anybody have an idea s to what the problem may be?



Mon, 17 May 2004 03:13:20 GMT  
 timeSetEvent
Without some method of initializing TLS, you can't execute local code on
a system thread.  So all the methods I cited are methods for getting the
code to run on your local thread.  In fact I'm pretty sure that the
first and last methods are effectively the same, because I think the
CCRP timers use the PostMessage trick (just a guess).

While I've never done it so I can't comment on its effectiveness, in
theory if you spawned a timer from an ActiveX component and applied one
of these methods, you could get what you're looking for: a separate
thread dedicated to handling the timer.  It still wouldn't run on the
system thread, but it wouldn't be running on your main thread either.

--

    Jim Mack
    MicroDexterity Inc
    www.microdexterity.com


Quote:
> Hi Jim,

> Thank you for the hints. I have one more quick question. For all of
the
> methods you mentioned (CCRP timer, global flag, raise an event), in
which
> thread does the processing of the timer event occur? I really need the
> processing to be done in the timer thread, so the main thread is free
to
> receive more calls from the client app.

> Anthony



> > I'd suggest that you look at the high-performance timer objects from
the
> > CCRP, which don't suffer from this problem.  I used a CCRP timer in
one
> > project and it worked (and continues to work) perfectly.
> > www.mvps.org/ccrp

> > I've also successfully used a timeSetTime callback by relying only
on
> > module level global variables.  By that I mean that the timer
callback
> > does only one thing: it increments a long integer (or perhaps sets a
> > boolean flag) which is declared Public in a standard module.

> > The main program runs in a tight loop in Sub Main, and checks each
time
> > around for the change of state of this variable (resets it to False
if
> > it's a flag).  When it pops, call a procedure containing the code
you
> > would have placed in the callback proc.

> > This works better than it sounds.  I use it to drive a data
acquisition
> > app which samples at 16 mSec intervals, and it works like a charm.

> > Yet another approach is to do nothing in the callback except post a
> > message to yourself -- use a message sink like Form_KeyUp that won't
get
> > used otherwise, and run your callback code in that event.

> > --

> >     Jim Mack
> >     MicroDexterity Inc
> >     www.microdexterity.com



> > > Hello Jim,

> > > You are absolutely right. When I took all the statements out of my
> > callback
> > > it did not crash.
> > > Now do you know how do I get around this problem?

> > > Anthony



> > > > This is likely the well-known "TLS" issue.  The callback is
> > occurring on
> > > > a separate thread, and VB6 does not properly initialize the
Thread
> > Local
> > > > Storage area (VB5 did, so this came as something of a surprise
to
> > many
> > > > people when they upgraded).

> > > > Try making your callback proc do absolutely nothing except
return.
> > If
> > > > it works correctly then this is almost certainly the problem.

> > > > --

> > > >     Jim Mack
> > > >     MicroDexterity Inc
> > > >     www.microdexterity.com



> > > > > I am calling the timeSetEvent function from an ActiveX EXE. It
is
> > > > called
> > > > > from one of the functions of the exposed class. The
timeSetEvent
> > > > function
> > > > > receives a function pointer, so I am passing it the address of
a
> > Sub
> > > > in my
> > > > > Utilities module. This is the call:
> > > > > timerID = timeSetEvent(timerT, tC.wPeriodMin, _
> > > > >                       AddressOf Utilities.viewTimerThreadFnc,
0,
> > > > > TIME_PERIODIC)
> > > > > The program crashes at this call. Unencouragingly enough, this
> > problem
> > > > does
> > > > > not occur in Debug mode, when I have my test app linked to the
> > .vbp,
> > > > but
> > > > > only when it is linked directly to the .exe.
> > > > > The crash occurs because there is an apparent unauthorized
memory
> > > > access.
> > > > > Does anybody have an idea s to what the problem may be?



Mon, 17 May 2004 07:05:50 GMT  
 timeSetEvent
Hi Jim,

Thanks a lot for your help.

Anthony


Quote:
> Without some method of initializing TLS, you can't execute local code on
> a system thread.  So all the methods I cited are methods for getting the
> code to run on your local thread.  In fact I'm pretty sure that the
> first and last methods are effectively the same, because I think the
> CCRP timers use the PostMessage trick (just a guess).

> While I've never done it so I can't comment on its effectiveness, in
> theory if you spawned a timer from an ActiveX component and applied one
> of these methods, you could get what you're looking for: a separate
> thread dedicated to handling the timer.  It still wouldn't run on the
> system thread, but it wouldn't be running on your main thread either.

> --

>     Jim Mack
>     MicroDexterity Inc
>     www.microdexterity.com



> > Hi Jim,

> > Thank you for the hints. I have one more quick question. For all of
> the
> > methods you mentioned (CCRP timer, global flag, raise an event), in
> which
> > thread does the processing of the timer event occur? I really need the
> > processing to be done in the timer thread, so the main thread is free
> to
> > receive more calls from the client app.

> > Anthony



> > > I'd suggest that you look at the high-performance timer objects from
> the
> > > CCRP, which don't suffer from this problem.  I used a CCRP timer in
> one
> > > project and it worked (and continues to work) perfectly.
> > > www.mvps.org/ccrp

> > > I've also successfully used a timeSetTime callback by relying only
> on
> > > module level global variables.  By that I mean that the timer
> callback
> > > does only one thing: it increments a long integer (or perhaps sets a
> > > boolean flag) which is declared Public in a standard module.

> > > The main program runs in a tight loop in Sub Main, and checks each
> time
> > > around for the change of state of this variable (resets it to False
> if
> > > it's a flag).  When it pops, call a procedure containing the code
> you
> > > would have placed in the callback proc.

> > > This works better than it sounds.  I use it to drive a data
> acquisition
> > > app which samples at 16 mSec intervals, and it works like a charm.

> > > Yet another approach is to do nothing in the callback except post a
> > > message to yourself -- use a message sink like Form_KeyUp that won't
> get
> > > used otherwise, and run your callback code in that event.

> > > --

> > >     Jim Mack
> > >     MicroDexterity Inc
> > >     www.microdexterity.com



> > > > Hello Jim,

> > > > You are absolutely right. When I took all the statements out of my
> > > callback
> > > > it did not crash.
> > > > Now do you know how do I get around this problem?

> > > > Anthony



> > > > > This is likely the well-known "TLS" issue.  The callback is
> > > occurring on
> > > > > a separate thread, and VB6 does not properly initialize the
> Thread
> > > Local
> > > > > Storage area (VB5 did, so this came as something of a surprise
> to
> > > many
> > > > > people when they upgraded).

> > > > > Try making your callback proc do absolutely nothing except
> return.
> > > If
> > > > > it works correctly then this is almost certainly the problem.

> > > > > --

> > > > >     Jim Mack
> > > > >     MicroDexterity Inc
> > > > >     www.microdexterity.com



> > > > > > I am calling the timeSetEvent function from an ActiveX EXE. It
> is
> > > > > called
> > > > > > from one of the functions of the exposed class. The
> timeSetEvent
> > > > > function
> > > > > > receives a function pointer, so I am passing it the address of
> a
> > > Sub
> > > > > in my
> > > > > > Utilities module. This is the call:
> > > > > > timerID = timeSetEvent(timerT, tC.wPeriodMin, _
> > > > > >                       AddressOf Utilities.viewTimerThreadFnc,
> 0,
> > > > > > TIME_PERIODIC)
> > > > > > The program crashes at this call. Unencouragingly enough, this
> > > problem
> > > > > does
> > > > > > not occur in Debug mode, when I have my test app linked to the
> > > .vbp,
> > > > > but
> > > > > > only when it is linked directly to the .exe.
> > > > > > The crash occurs because there is an apparent unauthorized
> memory
> > > > > access.
> > > > > > Does anybody have an idea s to what the problem may be?



Tue, 18 May 2004 01:28:16 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Help using the timeSetEvent api call

2. Is it possible to use timeSetEvent() in VB40?

3. timeSetEvent

4. timeSetEvent function problem

5. timeSetEvent API Call

6. Using callback multimedia timer (timesetevent) in VB

7. timeSetEvent (winmm.dll) & NT4.x

8. Looking for API info RE: TimeSetEvent

9. HELP: timeSetEvent() API

10. Problems using timeSetEvent()

11. API call Timesetevent returns strange identifier

12. timeSetEvent API Call

 

 
Powered by phpBB® Forum Software