Board index » cppbuilder » BCB4 pro: weird linker (and compiler) behaviour (long)

BCB4 pro: weird linker (and compiler) behaviour (long)

Hello all,

As I was rushing out a project last week, I stumbled upon some very
strange problems building my project. It took several hours (which I
could ill afford) to figure them out. Here is what happened:

To start out, my project consists of three packages, and an executable
with two data modules (one for tables, and one for reports), and five
normal forms. After several weeks of reconstructing the various
components in the packages, I finally got around to updating the forms.

When the last form was due (the most complex one in terms of event
handlers and controls), I got access violations from the IDE when I
attempted to open the form. I figured that this must have something to
do with the reconstuction of the packages, so after a few futile
attempts, I decided to remove the form from the project, backup it's
source files, and start from scratch with a new form.

I put back all of the controls needed, filled in some event handlers,
and saved the form, using the same filename as the one I was replacing.
However, I named the form itself differently, to follow the new naming
convention I had introduced.

I compiled and linked the project, and started the executable. Upon
initialisation, my program terminated with a VCL exception. It stated
that a property, 'Button1->OnClick' could not be found within my new
form !

So I went back into the IDE, opened up the form, and searched the .H and
.CPP files. No Button1 found. I switched to 'form as text', and searched
the object definitions. No Button1.

It was time for more drastic measures. So instead of a make, I tried a
full build. No difference. Next I deleted all .OBJ files before doing
the build. No difference. The next attempt was to delete all .OBJ files,
the precompiled header files (the VCL40.* in ($BCB)\lib), and the
project's .RES file. Still no difference.

The next attempt was to clean up the .DFM file of the form causing the
troubles. I did this by opening up the form as text in the editor,
deleting the .DFM from within the explorer, mutating the form by typing
a space, and then saving it again. Still, the problem remained.

I was slowly loosing my mind. The Button1 reference was nowhere in my
project's sources, and yet, each time I started the executable generated
by the IDE, it complained about the Button1->OnClick property not being
present.

So as a last resort, I took out Norton6's FileFind utility, and searched
my harddrive for 'Button1'. Sure enough, it found lots of files
containing it, but most of them were in the examples directory of
CBuilder, and thus not relevant.

A few, however, were interesting. It found references to Button1 in my
executable, it's .MAP file and it's .TDS file. I opened up the .MAP file
in the viewer, and sure enough, there was the Button1 definition.
However, it was listed within the class declarations of the previous
version of the form ! This was the one I had deleted, and whose .OBJ was
long gone from my hard drive. So how did it get into the map file??? I
don't use linker state files, so incremental link scewups are unlikely.

Then, after viewing the last file listed by FileFind, it hit me. This
was the old form's .DFM file from several months ago, before I had
reorganised my project. (I used to have all files in a single directory,
now it is organised so that each package and exec has it's own
directory). It was still in a directory listed at the search path of the
linker. And sure enough, it contained the definition for the
Button1->OnClick property.

So where the IDE takes the directory into account where you save your
form, when it reloads the form and it's .CPP file, the linker does not !
It simply takes the first .DFM file it finds that matches the forms
source file name.

To check the above, I created a new form in the project, placed some
buttons on it, assigned a few event handlers, and saved it. I then saved
it to it's proper directory, and altered the button's names. Sure
enough, when starting the exe, it started complaining about missing
Button?->OnCLick properties. This only went away, after I deleted the
now obsolete original .DFM file.

This was after a few hours of experimenting, and I thought I solved the
problems. Now something else surfaced. I made a few alterations to one
of the packages, and started a make. Make started compiling everything
(remember: I deleted all .OBJ files when I was figuring out the previous
problem), and the compiler stopped at the third source file with no less
than 14 errors ! I compiled this source at least several dozen times
without these errors, so I was puzzled.

It turned out that the compiler was complaining about TTable not being
declared. However, the source included VCL.H, and this one, in turn
includes the various .HPP files making up the VCL. It conditionally
includes the .HPP files containing the db-aware declarations of the VCL.
This includes both the db.hpp and dbtables.hpp. The first one contains,
amongst others, the TDataSet, while the second contains TTable.

The weird part is, that my source file not only contains TTable
references, but also TDataSet ones. The compiler accepted TDataSet, but
not TTable. Now I had this happen to me before (always after throwing
away the .OBJ files and precompiled header files), and upto now I
'solved' the problem by simply performing the make again. The errors
would then, mysteriously, disappear, just as mysteriously as they popped
up.

Not this time. I tried several builds and makes, but the errors kept
appearing. So I finally added an include for dbtables.hpp in my affected
source file. Luckily, the errors disappeared again. However, I have
absolutely no idea why these errors suddenly came up, after dosens of
compiles without any complaints from the compiler about TTable.

One last observation about the IDE itself. As most of you out there, I
have the final output path bug. So, as a rule, I have to correct this
path each time I start the IDE. However, there are many times I simply
forget it, and then get reminded of it by the linker saying it cannot
create the .TDS file.

The funny part is, this only happens after I start the IDE for the first
time. When I correct the output path, quit the IDE and restart, the
output path is still correct! Only when I restart Windows, the output
path is messed up again.

With regards,

Jan P. Dijkstra

--
*** SPAM blocker ***

To reply by email: remove removethis and mapson from the specified
address.

 

Re:BCB4 pro: weird linker (and compiler) behaviour (long)


: "Jan P. Dijkstra" <removethis....@mapson.lic.nl> wrote:

Quote
>As I was rushing out a project last week, I stumbled upon some very
>strange problems building my project.

I am sorry, Jan, but could you offer a short description of which kind of
problems you experienced?

You lost me at about line 20.

You might also want to mention which operating system and which version of
C++Builder you use.

--
General information:
  * Post to the right group - http://www.borland.com/newsgroups/
    * Do not cross- or multipost
      * Research at http://www.mers.com/searchsite.html

Stefan Hoffmeister - http://www.econos.de/
(TeamB - http://www.teamb.com/)

Re:BCB4 pro: weird linker (and compiler) behaviour (long)


Quote
"Stefan Hoffmeister (TeamB)" wrote:
> You lost me at about line 20.

> You might also want to mention which operating system and which version of
> C++Builder you use.

The real problem is stated after line 20. The lines upto that point
describe what I was doing before the problem occured, ie. the
circumstances under which the problem could arrise in the first place.

The real problem was that I had a form, which could not be instantiated
during runtime. The VCL exception was that a property could not be
found. In my case: 'Button1->OnClick'. When loaded in the IDE, the form
didn't have any definition, nor any reference to a Button1.

The bottom line was, that the linker linked in a different version of
the form's DFM file than the IDE was editing. This DFM *did* contain
both a definition for a Button1, and it's OnClick property.

The OS is Windows95 OSR 2, the Builder version is BCB4 pro, with both
patches applied.

--
*** SPAM blocker ***

To reply by email: remove removethis and mapson from the specified
address.

Re:BCB4 pro: weird linker (and compiler) behaviour (long)


"Jan P. Dijkstra" <removethis....@mapson.lic.nl> wrote in message
news:385605AB.E0D299CA@mapson.lic.nl...

Hi Jan,
This sounds familiar.  I've been in the 'let's start from scratch again'
position all too often.  I've never been able to determine what causes these
problems.  I've also had menus mysteriously disappear from the dfm.  Anyway!
some hints and comments.
Using NT4 sp6 and doing a lot of database work with Paradox8.

Quote

> I compiled and linked the project, and started the executable. Upon
> initialisation, my program terminated with a VCL exception. It stated
> that a property, 'Button1->OnClick' could not be found within my new
> form !

If the button is on your form but not in the header, clicking on the button
corrects the header.  This technique is important if you edit the dfm.

Quote
> It was time for more drastic measures. So instead of a make, I tried a
> full build. No difference. Next I deleted all .OBJ files before doing
> the build. No difference. The next attempt was to delete all .OBJ files,
> the precompiled header files (the VCL40.* in ($BCB)\lib), and the
> project's .RES file. Still no difference.

A build recreates the object files, so there's no point in deleting them.

I find deleting the .tds and .il* files helps.  Closing BCB is also
important, otherwise thing seem to be in preserved in memory.

Quote
> The next attempt was to clean up the .DFM file of the form causing the
> troubles. I did this by opening up the form as text in the editor,
> deleting the .DFM from within the explorer, mutating the form by typing
> a space, and then saving it again. Still, the problem remained.

I regularly convert dfm files to text and back them up so I can recover
objects that mysteriously disappear.
If you are going to edit the dfm file, convert it to text: close BCB: edit
the text file: delete the old dfm. Convert to dfm and finally open BCB.

Quote
> I was slowly loosing my mind.

Join the club.

Quote
> It turned out that the compiler was complaining about TTable not
> being declared.

I've noticed that if you have a program crash or abort a program run under
the de{*word*81}, BDBE is likely to be unstable.  Very occasionally some table
properties are reset.  On the larger projects I hard code table properties
rather than use the property editor.  So much for RAD.

Quote
> One last observation about the IDE itself. As most of you out there, I
> have the final output path bug. So, as a rule, I have to correct this
> path each time I start the IDE.

I frequently check the makefile to see if anything has screwed up.
Occasionally I've found that switching between projects can mess up your
paths.

len jones

Re:BCB4 pro: weird linker (and compiler) behaviour (long)


: "len jones" <ljo...@mnsi.net> wrote:

Quote
>I've noticed that if you have a program crash or abort a program run under
>the de{*word*81}, BDBE is likely to be unstable.  

This is quite normal, because if the program is zapped out of the process
space, your application does not unregister itself, allowing the BDE not
to clean up. That this can cause problems should go without saying,
shouldn't it?

--
General information:
  * Post to the right group - http://www.borland.com/newsgroups/
    * Do not cross- or multipost
      * Research at http://www.mers.com/searchsite.html

Stefan Hoffmeister - http://www.econos.de/
(TeamB - http://www.teamb.com/)

Re:BCB4 pro: weird linker (and compiler) behaviour (long)


Quote
"Stefan Hoffmeister (TeamB)" wrote:
> : "len jones" <ljo...@mnsi.net> wrote:

> >I've noticed that if you have a program crash or abort a program run under
> >the de{*word*81}, BDBE is likely to be unstable.

> This is quite normal, because if the program is zapped out of the process
> space, your application does not unregister itself, allowing the BDE not
> to clean up. That this can cause problems should go without saying,
> shouldn't it?

It should not have to.
Once a program runs in a de{*word*81} the de{*word*81} should be able to terminate the
program is such a way that the .DLL's the program loaded are unloaded as well.
This should result in the usual clean up for a database engine being used and
closing the database files. In otherwords, the de{*word*81} should be able to make
sure the necessary components are begin unregistered. Of course data that has
not been "committed" will be lost, but that is minor.

Don't worry, be Kneppie!
Jan

--
===============================================================
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.

http://www.smartsoft.cc/
---------------------------------------------------------------
http://www.pianoprincess.com/
http://www.mp3.com/pianoprincess
http://www.riffage.com/Bands/0,2939,2859,00.html
http://pianoprincess.iuma.com/
http://www.changemusic.com/piano_princess
===============================================================

Other Threads