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