Board index » delphi » "A call to an OS function failed"

"A call to an OS function failed"


2003-11-03 06:49:27 PM
delphi156
We have written an internal date time control and this has been working no problem for a while. Suddenly in design time we can not actually view a form, it pops up a dialog that mentions "A call to an OS function failed", but when I run it the form run time, it has no problem.
Some news groups, I have seen in Russian languages and chinese languages, they seem to get the same problem but I can not interpret how they have resolved it and why they get it. Is there any documented reason why I should get this?
I would be happy to submit the code if anyone could help.
Vince
 
 

Re:"A call to an OS function failed"

Author := "Vincent Farah";
|
| We have written an internal date time control and this has been
| working no problem for a while. Suddenly in design time we can't
| actually view a form, it pops up a dialog that mentions "A call to an
| OS function failed", but when I run it the form run time, it has no
| problem.
Start with debugging the design-time package. In the menu choose
Run/Parameters and in Host Application specify delphi32.exe (full
path). Then run the package like any exe. In the second instance of
delphi try to open the form and hopefully the de{*word*81} of the first
instance will stop at the offending api function.
HTH
--
Constantine
 

Re:"A call to an OS function failed"

Thanks Constantine! In actual fact I have already done this but I think it is an IDE problem because it comes and goes. It is so random that when I tried to do what you suggested, I couldn't get it to raise the error. It then dissappears for a week and then a week/day later we can not actually get into forms in design time. And some times all it takes is a recompile or something unrelated to science to get it working. Thanks for the suggestion but I had already tried to do it this way to no avail.
Vince
"Constantine Yannakopoulos" <XXXX@XXXXX.COM>writes:
Quote
Author := "Vincent Farah";

|
| We have written an internal date time control and this has been
| working no problem for a while. Suddenly in design time we can't
| actually view a form, it pops up a dialog that mentions "A call to an
| OS function failed", but when I run it the form run time, it has no
| problem.

Start with debugging the design-time package. In the menu choose
Run/Parameters and in Host Application specify delphi32.exe (full
path). Then run the package like any exe. In the second instance of
delphi try to open the form and hopefully the de{*word*81} of the first
instance will stop at the offending api function.

HTH

--
Constantine
 

Re:"A call to an OS function failed"

Author := "Vincent Farah";
|
| Thanks Constantine! In actual fact I have already done this but I
| think it is an IDE problem because it comes and goes. It is so random
| that when I tried to do what you suggested, I couldn't get it to
| raise the error. It then dissappears for a week and then a week/day
| later we can not actually get into forms in design time. And some times
| all it takes is a recompile or something unrelated to science to get
| it working. Thanks for the suggestion but I had already tried to do
| it this way to no avail.
Sounds like a threading problem... strange. Are there any threads in
the design-time package?
There is another approach: Jedi Code Library gives you the ability to
generate a stack trace in your program (JclCreateStackList in unit
JclDebug). For plain exe's it requires a map file to get the function
names but for packages it uses the exported mangled names from the bpl.
You could install from a design-time package an exception handler that
will display a stack trace when an exception occurs in the IDE. This
can be a little bit irritating for "regular" IDE exception messages but
when the problem decides to emerge again you will have a stack trace to
inspect. This technique has proven very convenient to me for
difficult-to-debug bugs in design-time packages.
HTH
--
Constantine
 

Re:"A call to an OS function failed"

I have no threads inside. Infact the strange part is that it is
so elementary. That is the part I can not get my head arround and
the fact that it has been working for so long and all of a
sudden it goes bang. Thanks very much for your help. I will give that a go.
Vince
"Constantine Yannakopoulos" <XXXX@XXXXX.COM>writes:
Quote
Author := "Vincent Farah";

|
| Thanks Constantine! In actual fact I have already done this but I
| think it is an IDE problem because it comes and goes. It is so random
| that when I tried to do what you suggested, I couldn't get it to
| raise the error. It then dissappears for a week and then a week/day
| later we can not actually get into forms in design time. And some times
| all it takes is a recompile or something unrelated to science to get
| it working. Thanks for the suggestion but I had already tried to do
| it this way to no avail.

Sounds like a threading problem... strange. Are there any threads in
the design-time package?

There is another approach: Jedi Code Library gives you the ability to
generate a stack trace in your program (JclCreateStackList in unit
JclDebug). For plain exe's it requires a map file to get the function
names but for packages it uses the exported mangled names from the bpl.
You could install from a design-time package an exception handler that
will display a stack trace when an exception occurs in the IDE. This
can be a little bit irritating for "regular" IDE exception messages but
when the problem decides to emerge again you will have a stack trace to
inspect. This technique has proven very convenient to me for
difficult-to-debug bugs in design-time packages.

HTH

--
Constantine