Board index » off-topic » Debbuger drastically slows down under clx/thread/callback/label component

Debbuger drastically slows down under clx/thread/callback/label component


2003-10-30 11:04:26 AM
off-topic19
Dear Sirs,
I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
(under Windows XP and CLX): I use a callback function to respond to a
trigger signal from a digital I/O board (via its DLL that is probably a VCL
one, which generates a thread as a response to the trigger signal) . I
simply increment a counter
inside the callback function (for testing purposes) that is put in
applications form as a label field for viewing. I put a breakpoint inside
the callback function and start the application.
The callback function is correclty called (inside the context of the DLL
thread) when a digital signal trigger
comes into assigned input pins, but when I use alternately the "step over",
"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
not important), suddenly the de{*word*81} seems to slow down, taking its actions
in a scale of minutes! It also affects the iteraction with other processes
outside Borlandīs environment, even the "Task manager" is slowed down (I am
unable to "kill" the "not responding" process).
Initialy I found it could be a crash, but testing at another (faster)
computer I was able to reproduce the slowdown and I realized that in some
point in the future (aproximately 20 minutes away), I recovered full control
over the PC.
There was no error message sent, neither from Borland environment, nor from
Windows environment. From that point on I could proceed with step by step
debugging.
My application seems to work well as stand alone
application (outside Borlandīs environment).
I already updated with Service Pack 4 from Borland and tryed other obvious
measures, that is, reinstall Windows, update my drivers for the I/O board
ant test at other PC.
I donīt know if the Clx Label component I put into the form (MDI Child)
(whose Caption property is used to show counter value) being updated inside
the Callback function called by the thread generated by the VCL DLL does
not work well...
Can anyone help me on this issue? Anyway, I'm not sure if this bug has
anything to do with a callback function in a thread context or the Label
component update!!!
Regards,
 
 

Re:Debbuger drastically slows down under clx/thread/callback/label component

Sorry,
I thought BDE standed for Borland Developmento Environment!
Living is learning.
"Bill Todd" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
Your question has nothing to do with the Borland Database Engine
(BDE). You should post this question in the C++ Builder IDE newsgroup.


--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
 

Re:Debbuger drastically slows down under clx/thread/callback/label component

Dear Sirs,
I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
(under Windows XP and CLX): I use a callback function to respond to a
trigger signal from a digital I/O board (via its DLL that is probably a VCL
one, which generates a thread as a response to the trigger signal) . I
simply increment a counter
inside the callback function (for testing purposes) that is put in
applications form as a label field for viewing. I put a breakpoint inside
the callback function and start the application.
The callback function is correclty called (inside the context of the DLL
thread) when a digital signal trigger
comes into assigned input pins, but when I use alternately the "step over",
"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
not important), suddenly the de{*word*81} seems to slow down, taking its actions
in a scale of minutes! It also affects the iteraction with other processes
outside Borlandīs environment, even the "Task manager" is slowed down (I am
unable to "kill" the "not responding" process).
Initialy I found it could be a crash, but testing at another (faster)
computer I was able to reproduce the slowdown and I realized that in some
point in the future (aproximately 20 minutes away), I recovered full control
over the PC.
There was no error message sent, neither from Borland environment, nor from
Windows environment. From that point on I could proceed with step by step
debugging.
My application seems to work well as stand alone
application (outside Borlandīs environment).
I already updated with Service Pack 4 from Borland and tryed other obvious
measures, that is, reinstall Windows, update my drivers for the I/O board
ant test at other PC.
I donīt know if the Clx Label component I put into the form (MDI Child)
(whose Caption property is used to show counter value) being updated inside
the Callback function called by the thread generated by the VCL DLL does
not work well...
Can anyone help me on this issue? Anyway, I'm not sure if this bug has
anything to do with a callback function in a thread context or the Label
component update!!!
Regards,
Hermes
 

{smallsort}

Re:Debbuger drastically slows down under clx/thread/callback/label component

It seems that the slowdown occurs whenever the application goes to update
the application's form screen, i.e., when it returns from the code to the
application!
(It happens with any F7, F8 or F9 keys, once it is the point that process
will return to application's form - that I noticed now)
"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...
Quote
Dear Sirs,

I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
(under Windows XP and CLX): I use a callback function to respond to a
trigger signal from a digital I/O board (via its DLL that is probably a
VCL
one, which generates a thread as a response to the trigger signal) . I
simply increment a counter
inside the callback function (for testing purposes) that is put in
applications form as a label field for viewing. I put a breakpoint inside
the callback function and start the application.

The callback function is correclty called (inside the context of the DLL
thread) when a digital signal trigger
comes into assigned input pins, but when I use alternately the "step
over",
"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
not important), suddenly the de{*word*81} seems to slow down, taking its
actions
in a scale of minutes! It also affects the iteraction with other processes
outside Borlandīs environment, even the "Task manager" is slowed down (I
am
unable to "kill" the "not responding" process).

Initialy I found it could be a crash, but testing at another (faster)
computer I was able to reproduce the slowdown and I realized that in some
point in the future (aproximately 20 minutes away), I recovered full
control
over the PC.

There was no error message sent, neither from Borland environment, nor
from
Windows environment. From that point on I could proceed with step by step
debugging.

My application seems to work well as stand alone
application (outside Borlandīs environment).

I already updated with Service Pack 4 from Borland and tryed other obvious
measures, that is, reinstall Windows, update my drivers for the I/O board
ant test at other PC.

I donīt know if the Clx Label component I put into the form (MDI Child)
(whose Caption property is used to show counter value) being updated
inside
the Callback function called by the thread generated by the VCL DLL does
not work well...

Can anyone help me on this issue? Anyway, I'm not sure if this bug has
anything to do with a callback function in a thread context or the Label
component update!!!

Regards,


Hermes


 

Re:Debbuger drastically slows down under clx/thread/callback/label component

Hi Hermes,
I've been writing a multi-threaded DLL recently too.
Do you think it could have something to do with the DLL being sensitive
to how long the callback takes to return? I've noticed sometimes that
debugging multi-threaded apps is not so straight-forward and can
sometimes cause unpredictable behaviour.
Have you had a look at the task manager (performance) to see if cpu
cycles shoots up when you get this slowdown? Maybe the DLL isn't robust
and gets itself into a tight loop somehow if the callback takes too
long? Maybe test by putting in Sleep()'s of various times in the
callback and see if there is a threshold at which you see the problem.
Do you have the source code for the DLL?
Prem.
Hermes Aguiar Magalhães wrote:
Quote
It seems that the slowdown occurs whenever the application goes to update
the application's form screen, i.e., when it returns from the code to the
application!

(It happens with any F7, F8 or F9 keys, once it is the point that process
will return to application's form - that I noticed now)

"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...

>Dear Sirs,
>
>I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
>(under Windows XP and CLX): I use a callback function to respond to a
>trigger signal from a digital I/O board (via its DLL that is probably a

VCL

>one, which generates a thread as a response to the trigger signal) . I
>simply increment a counter
>inside the callback function (for testing purposes) that is put in
>applications form as a label field for viewing. I put a breakpoint inside
>the callback function and start the application.
>
>The callback function is correclty called (inside the context of the DLL
>thread) when a digital signal trigger
>comes into assigned input pins, but when I use alternately the "step

over",

>"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
>not important), suddenly the de{*word*81} seems to slow down, taking its

actions

>in a scale of minutes! It also affects the iteraction with other processes
>outside Borlandīs environment, even the "Task manager" is slowed down (I

am

>unable to "kill" the "not responding" process).
>
>Initialy I found it could be a crash, but testing at another (faster)
>computer I was able to reproduce the slowdown and I realized that in some
>point in the future (aproximately 20 minutes away), I recovered full

control

>over the PC.
>
>There was no error message sent, neither from Borland environment, nor

from

>Windows environment. From that point on I could proceed with step by step
>debugging.
>
>My application seems to work well as stand alone
>application (outside Borlandīs environment).
>
>I already updated with Service Pack 4 from Borland and tryed other obvious
>measures, that is, reinstall Windows, update my drivers for the I/O board
>ant test at other PC.
>
>I donīt know if the Clx Label component I put into the form (MDI Child)
>(whose Caption property is used to show counter value) being updated

inside

>the Callback function called by the thread generated by the VCL DLL does
>not work well...
>
>Can anyone help me on this issue? Anyway, I'm not sure if this bug has
>anything to do with a callback function in a thread context or the Label
>component update!!!
>
>Regards,
>
>
>Hermes
>
>
 

Re:Debbuger drastically slows down under clx/thread/callback/label component

Prem,
It does not seem to be about time to return from callback Sometimes it
happens at beginning of my simulation, sometimes after a longer simulation.
Sometimes I go out to do anything else with the process inside the callback
function (at a breakcpoint) for almost half an hour and there is no problem.
It seems that the problem is in the de{*word*81}, because outside Borlandīs
environment the program works well.
I also do not have the source code (it is from a third-party video capture
board vendor). My CPU is not stuck, its activity remains under 2%, but
sometimes I see a lot of Hard disk activity (not always). But to see the
window from the task manager I had to wait almost an hour!!!
I am quite now erasing all labels from my childWin form, and if that does
not work, next I will try "treat enum types as ints". Iīve read in another
Borlandīs newsletter group that VCL DLLs being called from CLX programs
without this condition set up have strange behaviours.
The strange thing is that IDE becomes very slow, but no error occurs (at
least no error message is generated)! I am over this issue already for 3
weeks.
Regards,
Hermes
"Prem" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
Hi Hermes,

I've been writing a multi-threaded DLL recently too.

Do you think it could have something to do with the DLL being sensitive
to how long the callback takes to return? I've noticed sometimes that
debugging multi-threaded apps is not so straight-forward and can
sometimes cause unpredictable behaviour.

Have you had a look at the task manager (performance) to see if cpu
cycles shoots up when you get this slowdown? Maybe the DLL isn't robust
and gets itself into a tight loop somehow if the callback takes too
long? Maybe test by putting in Sleep()'s of various times in the
callback and see if there is a threshold at which you see the problem.

Do you have the source code for the DLL?

Prem.


Hermes Aguiar Magalhães wrote:

>It seems that the slowdown occurs whenever the application goes to
update
>the application's form screen, i.e., when it returns from the code to
the
>application!
>
>(It happens with any F7, F8 or F9 keys, once it is the point that
process
>will return to application's form - that I noticed now)
>
>"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
>mensagem news: XXXX@XXXXX.COM ...
>
>>Dear Sirs,
>>
>>I am experiencing a problem that seems to be from C++ Builder 6
De{*word*81}
>>(under Windows XP and CLX): I use a callback function to respond to a
>>trigger signal from a digital I/O board (via its DLL that is probably a
>
>VCL
>
>>one, which generates a thread as a response to the trigger signal) . I
>>simply increment a counter
>>inside the callback function (for testing purposes) that is put in
>>applications form as a label field for viewing. I put a breakpoint
inside
>>the callback function and start the application.
>>
>>The callback function is correclty called (inside the context of the
DLL
>>thread) when a digital signal trigger
>>comes into assigned input pins, but when I use alternately the "step
>
>over",
>
>>"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used
are
>>not important), suddenly the de{*word*81} seems to slow down, taking its
>
>actions
>
>>in a scale of minutes! It also affects the iteraction with other
processes
>>outside Borlandīs environment, even the "Task manager" is slowed down
(I
>
>am
>
>>unable to "kill" the "not responding" process).
>>
>>Initialy I found it could be a crash, but testing at another (faster)
>>computer I was able to reproduce the slowdown and I realized that in
some
>>point in the future (aproximately 20 minutes away), I recovered full
>
>control
>
>>over the PC.
>>
>>There was no error message sent, neither from Borland environment, nor
>
>from
>
>>Windows environment. From that point on I could proceed with step by
step
>>debugging.
>>
>>My application seems to work well as stand alone
>>application (outside Borlandīs environment).
>>
>>I already updated with Service Pack 4 from Borland and tryed other
obvious
>>measures, that is, reinstall Windows, update my drivers for the I/O
board
>>ant test at other PC.
>>
>>I donīt know if the Clx Label component I put into the form (MDI
Child)
>>(whose Caption property is used to show counter value) being updated
>
>inside
>
>>the Callback function called by the thread generated by the VCL DLL
does
>>not work well...
>>
>>Can anyone help me on this issue? Anyway, I'm not sure if this bug has
>>anything to do with a callback function in a thread context or the
Label
>>component update!!!
>>
>>Regards,
>>
>>
>>Hermes
>>
>>

 

Re:Debbuger drastically slows down under clx/thread/callback/label component

Folks!
Definitely the problem is related to the Clx "Label" component:
At a first try, I removed from the Child form only the Label whose "Caption"
property was updated with my counter value (that was put there only for test
purposes). The problem remained.
After that I removed all four Labels that were present at my form. The
slowdown has gone!!!
The idea of trying over the removal of the Clx Label components from the
form came from a reported bug at the cppbuilder.clx.components.using
newsgroup, that is reproduced below (after the "dashes").
Is anyone from Borland reading this message, so that I could have a return
on that bug solution? Or Iīll remain forbidden to use CLX "Label"
components in my application?
Regards,
Hermes
----------------------------------------------------------------------------
-------------
Alex,
It seems my problem has connections with yours: I am also running an EXE
file from Borland C++ Builder 6 with a DLL (probably a VCL one) beneath,
from my I/O card vendor. I am also using callback mechanism to process a
digital trigger signal dispatched from a thread. I also use "Caption"
property from a label in a CLS form (to make visual the triggering) in
context of a thread, but I did not notice the misbehaviour you related at
the Label itself. Read my problem report below.
Is there any anyone that could help us on the following problem? Description
follows
I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
(under Windows XP and CLX): I use a callback function to respond to a
trigger signal from a digital I/O board. I simply increment a counter
inside the callback function (for testing purposes) that is put in
applications form as a label field for viewing. I put a breakpoint inside
the callback function and start the application.
The callback function is correclty called when a digital signal trigger
comes into assigned input pins, but when I use alternately the "step over",
"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
not important), suddenly the de{*word*81} seems to slow down, taking its actions
in a scale of minutes! It also affects the iteractiion with other processes
outside Borlandīs environment, even the "Task manager" is slowed down.
Initialy I found it could be a crash, but testing at another (faster)
computer I was able to reproduce the slowdown and I realized that in some
point in the future (aproximately 20 minutes away), I recovered full control
over the PC.
There was no error message sent, neither from Borland environment, nor from
Windows environment. My application seems to work well as stand alone
application (outside Borlandīs environment).
I already updated with Service Pack 4 from Borland and tryed other obvious
measures, that is, reinstall Windows, update my drivers for the I/O board
ant test at other PC.
Can anyone help me on this issue? Anyway, I'm not sure if this bug has
anything to do with a callback function.
Regards,
"Alex" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
Hi,
I am working on a project that consists from a C++ Builder 6 EXE (CLX form
and controls), and a Visual C++ 6 DLL that runs beneath.
Inside the DLL there are several threads running, and from time to time
one
of these threads calls a function in the EXE (using a callback mechanism).
This function does several things, but mainly it updates some controls on
the form - labels, checkboxes, comboboxes etc. This function is in a
critical section so once it begins, it must finish before another thread
can
call it. So in other words, all the controls are updated in a context of a
thread.

Everything works great, except of one scenario - if the control that is to
be updated is a CLX label (its "caption" property, to be precise), and it
is
currently visible on the screen, the EXE crashes.

All other controls seem to be updated just fine, it's just this label that
keeps crashing. Also, it does not seem to happen on all machines, and even
when it happens, it happens intermittently. Really strange.

If a put a breakpoint, I see that the statement
labelname->Caption="something"; is called and then the exception occures.
Again - this happens only if the label is visible on the form. If the form
is minimized or the label's parent tab is not the active one, everything
is
ok.

I am working Windows 2000 systems, SP 4.

Has anyone seen such thing before? Could it be that CLX labels have a
limitation in working with threads? Or is it a bug? Any suggested
workarounds?

Thanks
Alex


"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...
Quote
Dear Sirs,

I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
(under Windows XP and CLX): I use a callback function to respond to a
trigger signal from a digital I/O board (via its DLL that is probably a
VCL
one, which generates a thread as a response to the trigger signal) . I
simply increment a counter
inside the callback function (for testing purposes) that is put in
applications form as a label field for viewing. I put a breakpoint inside
the callback function and start the application.

The callback function is correclty called (inside the context of the DLL
thread) when a digital signal trigger
comes into assigned input pins, but when I use alternately the "step
over",
"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used are
not important), suddenly the de{*word*81} seems to slow down, taking its
actions
in a scale of minutes! It also affects the iteraction with other processes
outside Borlandīs environment, even the "Task manager" is slowed down (I
am
unable to "kill" the "not responding" process).

Initialy I found it could be a crash, but testing at another (faster)
computer I was able to reproduce the slowdown and I realized that in some
point in the future (aproximately 20 minutes away), I recovered full
control
over the PC.

There was no error message sent, neither from Borland environment, nor
from
Windows environment. From that point on I could proceed with step by step
debugging.

My application seems to work well as stand alone
application (outside Borlandīs environment).

I already updated with Service Pack 4 from Borland and tryed other obvious
measures, that is, reinstall Windows, update my drivers for the I/O board
ant test at other PC.

I donīt know if the Clx Label component I put into the form (MDI Child)
(whose Caption property is used to show counter value) being updated
inside
the Callback function called by the thread generated by the VCL DLL does
not work well...

Can anyone help me on this issue? Anyway, I'm not sure if this bug has
anything to do with a callback function in a thread context or the Label
component update!!!

Regards,


Hermes


 

Re:Debbuger drastically slows down under clx/thread/callback/label component

If that is of any Help to Borland's developmento team to fix the bug:
I simply put a clx Label into the MDI Child form again and the problem
happened again.
When I went to Run/Program reset/ and tryed to stop it, a timeout message
came asking me choose between abort/rety/ignore. I clicked "abort" and the
following message error came:
Access violation at address 0056327D in module 'coreide60.bpl'. Read of
address 00000000.
After that, I successfully returned to IDE.
If I should have waited for about 30 minutes probably it should be out of
"slowdown" and this error would never occur,
Regards,
Hermes
"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...
Quote
Folks!

Definitely the problem is related to the Clx "Label" component:
At a first try, I removed from the Child form only the Label whose
"Caption"
property was updated with my counter value (that was put there only for
test
purposes). The problem remained.

After that I removed all four Labels that were present at my form. The
slowdown has gone!!!

The idea of trying over the removal of the Clx Label components from the
form came from a reported bug at the cppbuilder.clx.components.using
newsgroup, that is reproduced below (after the "dashes").

Is anyone from Borland reading this message, so that I could have a return
on that bug solution? Or Iīll remain forbidden to use CLX "Label"
components in my application?

Regards,

Hermes

--------------------------------------------------------------------------
 

Re:Debbuger drastically slows down under clx/thread/callback/label component

The problem does not seem to happen when my application is minimized.
Hermes
"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...
Quote
If that is of any Help to Borland's developmento team to fix the bug:

I simply put a clx Label into the MDI Child form again and the problem
happened again.
When I went to Run/Program reset/ and tryed to stop it, a timeout message
came asking me choose between abort/rety/ignore. I clicked "abort" and the
following message error came:

Access violation at address 0056327D in module 'coreide60.bpl'. Read of
address 00000000.

After that, I successfully returned to IDE.
If I should have waited for about 30 minutes probably it should be out of
"slowdown" and this error would never occur,

Regards,

Hermes

"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
mensagem news: XXXX@XXXXX.COM ...
>Folks!
>
>Definitely the problem is related to the Clx "Label" component:
>At a first try, I removed from the Child form only the Label whose
"Caption"
>property was updated with my counter value (that was put there only for
test
>purposes). The problem remained.
>
>After that I removed all four Labels that were present at my form. The
>slowdown has gone!!!
>
>The idea of trying over the removal of the Clx Label components from the
>form came from a reported bug at the cppbuilder.clx.components.using
>newsgroup, that is reproduced below (after the "dashes").
>
>Is anyone from Borland reading this message, so that I could have a
return
>on that bug solution? Or Iīll remain forbidden to use CLX "Label"
>components in my application?
>
>Regards,
>
>Hermes
>

--------------------------------------------------------------------------
--
>-------------
>
>Alex,
>
>It seems my problem has connections with yours: I am also running an EXE
>file from Borland C++ Builder 6 with a DLL (probably a VCL one) beneath,
>from my I/O card vendor. I am also using callback mechanism to process a
>digital trigger signal dispatched from a thread. I also use "Caption"
>property from a label in a CLS form (to make visual the triggering) in
>context of a thread, but I did not notice the misbehaviour you related
at
>the Label itself. Read my problem report below.
>
>Is there any anyone that could help us on the following problem?
Description
>follows
>
>
>
>I am experiencing a problem that seems to be from C++ Builder 6 De{*word*81}
>(under Windows XP and CLX): I use a callback function to respond to a
>trigger signal from a digital I/O board. I simply increment a counter
>inside the callback function (for testing purposes) that is put in
>applications form as a label field for viewing. I put a breakpoint
inside
>the callback function and start the application.
>
>The callback function is correclty called when a digital signal trigger
>comes into assigned input pins, but when I use alternately the "step
over",
>"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used
are
>not important), suddenly the de{*word*81} seems to slow down, taking its
actions
>in a scale of minutes! It also affects the iteractiion with other
processes
>outside Borlandīs environment, even the "Task manager" is slowed down.
>
>Initialy I found it could be a crash, but testing at another (faster)
>computer I was able to reproduce the slowdown and I realized that in
some
>point in the future (aproximately 20 minutes away), I recovered full
control
>over the PC.
>
>There was no error message sent, neither from Borland environment, nor
from
>Windows environment. My application seems to work well as stand alone
>application (outside Borlandīs environment).
>
>I already updated with Service Pack 4 from Borland and tryed other obvio
us
>measures, that is, reinstall Windows, update my drivers for the I/O
board
>ant test at other PC.
>Can anyone help me on this issue? Anyway, I'm not sure if this bug has
>anything to do with a callback function.
>
>Regards,
>
>"Alex" < XXXX@XXXXX.COM >escreveu na mensagem
>news: XXXX@XXXXX.COM ...
>>Hi,
>>I am working on a project that consists from a C++ Builder 6 EXE (CLX
form
>>and controls), and a Visual C++ 6 DLL that runs beneath.
>>Inside the DLL there are several threads running, and from time to
time
>one
>>of these threads calls a function in the EXE (using a callback
mechanism).
>>This function does several things, but mainly it updates some controls
on
>>the form - labels, checkboxes, comboboxes etc. This function is in a
>>critical section so once it begins, it must finish before another
thread
>can
>>call it. So in other words, all the controls are updated in a context
of
a
>>thread.
>>
>>Everything works great, except of one scenario - if the control that
is
to
>>be updated is a CLX label (its "caption" property, to be precise), and
it
>is
>>currently visible on the screen, the EXE crashes.
>>
>>All other controls seem to be updated just fine, it's just this label
that
>>keeps crashing. Also, it does not seem to happen on all machines, and
even
>>when it happens, it happens intermittently. Really strange.
>>
>>If a put a breakpoint, I see that the statement
>>labelname->Caption="something"; is called and then the exception
occures.
>>Again - this happens only if the label is visible on the form. If the
form
>>is minimized or the label's parent tab is not the active one,
everything
>is
>>ok.
>>
>>I am working Windows 2000 systems, SP 4.
>>
>>Has anyone seen such thing before? Could it be that CLX labels have a
>>limitation in working with threads? Or is it a bug? Any suggested
>>workarounds?
>>
>>Thanks
>>Alex
>>
>>
>
>
>
>
>"Hermes Aguiar Magalhães" < XXXX@XXXXX.COM >escreveu na
>mensagem news: XXXX@XXXXX.COM ...
>>Dear Sirs,
>>
>>I am experiencing a problem that seems to be from C++ Builder 6
De{*word*81}
>>(under Windows XP and CLX): I use a callback function to respond to a
>>trigger signal from a digital I/O board (via its DLL that is probably
a
>VCL
>>one, which generates a thread as a response to the trigger signal) .
I
>>simply increment a counter
>>inside the callback function (for testing purposes) that is put in
>>applications form as a label field for viewing. I put a breakpoint
inside
>>the callback function and start the application.
>>
>>The callback function is correclty called (inside the context of the
DLL
>>thread) when a digital signal trigger
>>comes into assigned input pins, but when I use alternately the "step
>over",
>>"trace into" or "run" (F8, F7 OR F9) keys (the order the keys are used
are
>>not important), suddenly the de{*word*81} seems to slow down, taking its
>actions
>>in a scale of minutes! It also affects the iteraction with other
processes
>>outside Borlandīs environment, even the "Task manager" is slowed down
(I
>am
>>unable to "kill" the "not responding" process).
>>
>>Initialy I found it could be a crash, but testing at another (faster)
>>computer I was able to reproduce the slowdown and I realized that in
some
>>point in the future (aproximately 20 minutes away), I recovered full
>control
>>over the PC.
>>
>>There was no error message sent, neither from Borland environment, nor
>from
>>Windows environment. From that point on I could proceed with step by
step
>>debugging.
>>
>>My application seems to work well as stand alone
>>application (outside Borlandīs environment).
>>
>>I already updated with Service Pack 4 from Borland and tryed other
obvious
>>measures, that is, reinstall Windows, update my drivers for the I/O
board
>>ant test at other PC.
>>
>>I donīt know if the Clx Label component I put into the form (MDI
Child)
>>(whose Caption property is used to show counter value) being updated
>inside
>>the Callback function called by the thread generated by the VCL DLL
does
>>not work well...
>>
>>Can anyone help me on this issue? Anyway, I'm not sure if this bug has
>>anything to do with a callback function in a thread context or the
Label
>>component update!!!
>>
>>Regards,
>>
>>
>>Hermes
>>
>>
>
>