Board index » cppbuilder » Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Your biggest BCB complaints? (was Re: cpp_open_letter email address)


2004-01-17 03:40:07 AM
cppbuilder65
Duane Hebert wrote:
Quote
Sorry for the rant but I'm spending WAY too much time dealing with BCB6 bugs that have
been documented for years and never fixed. We're getting very close to choosing an
alternative. The people on these groups have been great in assisting me with these
problems. I will miss the Borland community but this is starting to affect our p/l. We're
not going to have a choice.
Duane,
I'm curious, what are your top beefs with BCB in terms of bugs that reduce
productivity? Some of mine:
1) I've wasted days on weird bugs involving names of controls where either things
won't link or there are errors starting up the exe due to resources not found. I've
had to go into .dfm files and try to change names to make stuff work. In some cases
the control name errors seemed to come out of nowhere. Though with item 4 below I can
at least in those particular cases trace the problems back to something I did.
2) When I first start BCB I often have to compile a single unit before being able to
do a Make. Otherwise I get an access violation if I first try to do Make.
4) Something I've found that is extremely verboten to do: Do not change source code
variable names or class names when the names can be changed in properties. Otherwise
the stuff can get out of sync in ways that are just impossible to fix. I learned that
one the hard way after I did it a couple of times. Though in one case I started
changing the source because it suddenly couldn't find the form at run-time even
though it was listed to be auto-generated. The pointer would end up being
uninitialized. In that case I had to end up making a new form from scratch with a
slightly different name. Then invoking that new form worked where invoking the still
present old form didn't.
5) I have one new project file I had recently created from scratch for an existing
project (because the old project file had something else I couldn't figure out how to
fix) that when I open the project file it says:
Error Reading Form
Class TNTabEd not found.
I can't figure out which form is involved. I opened each one individually with no
error message. I searched the entire project source and did not find this file. BCB
at the very least ought to tell you when it gives that error dialog what form it is
getting the name from. I had to go back to a different older project file and managed
to get it updated and working again as a way to side step the problem.
My biggest BCB problems relate to dfm files and bpr files. When things get out of
whack it can be extremely difficult to try to recover. BCB does not provide enough
visibility into where it gets information and why it is complaining in a variety of
situations. I don't mind it getting out of whack as much as I mind not having a clear
path go to down to be able to figure out the causes and to recover.
Creating a new project from scratch is a real pain for a big and long-running
project. Also, upgrading across BCB versions causes weird problems.
The underlying theme for me is project management and scalability. I don't want to
get into positions where I can't build and run the project. I don't want inexplicable
linker errors or app process initialization errors.
At least BCBX lets you configure different builds off a single project definition.
But will it ever support Win32 VCL and if it does will it support it at least as well
as BCB does? Or will the new designer be more buggy?
 
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
I'm curious, what are your top beefs with BCB in terms of bugs that reduce
productivity? Some of mine:
Which version of BCB are you using? Most of the IDE/BPR fun got better for us
after upgrading to BCB6.
On a daily basis I have to deal with the build stopping at the first rc file problem.
(Reported on QC2072 8/11/2002- one of the highest voted )
Recently I spent 3 days looking for a problem where creating a std::string caused a std::bad_cast
exception. I found a similar report on QC 2050 8/9/2002 I can either change my code
(which is correct IMO) or stop using codeguard.
Before that, there was the problem with trying to use placement new/delete with nothrow. Crashed
with
codeguard on and dumped into RogueWave (we're using StlPort or so we thought).
That one was on QC3581 2/20/2003
(this time, we changed the code as it's not clear where the problem actually is)
At this point, I can't use Codeguard without the bad cast errors intermittently popping up (
right before the winhelpviewer memory leak which is BTW also on QC4152 4/18/2003)
I have to be careful how I name my files or else the linker gets screwed up. It seems that the
filename
is parsed by the first eight characters so if I have a cpp file called somename.cpp and another
called
somenamemanager.cpp it will matter how they are linked. I don't know if this has been reported to
QC but Chris, Ed and those guys know about this. This kind of sucks when using code from
other departments.
Then there's the everyday stuff to deal with like the screwey ctor/dtor order from delphi
that can cause some bizarre results. The fact that the dtor of the main form doesn't
get called when a windows user logs off (thanks to Remy's help we traced this and I
had to add some watchdog disable code to onclosequery() event)
I have to say that most of the IDE bugs seemed to go away after I removed the class explorer. It
seems better than BCB5.
I spent a week or so trying to import one of my projects into CBX. I got it to almost work
but got stuck with the merge/linker bug. I reported a couple of bugs to QC. Both are opened.
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Duane Hebert wrote:
Quote
>I'm curious, what are your top beefs with BCB in terms of bugs that reduce
>productivity? Some of mine:

Which version of BCB are you using? Most of the IDE/BPR fun got better for us
after upgrading to BCB6.
BCB v6 sp4.
Quote
On a daily basis I have to deal with the build stopping at the first rc file problem.
(Reported on QC2072 8/11/2002- one of the highest voted )
How do you get a build working again when that happens? I haven't seen that problem yet.
Quote
Recently I spent 3 days looking for a problem where creating a std::string caused a std::bad_cast
exception. I found a similar report on QC 2050 8/9/2002 I can either change my code
(which is correct IMO) or stop using codeguard.
I'd change my code rather than give up on CodeGuard.
Quote

Before that, there was the problem with trying to use placement new/delete with nothrow. Crashed
with codeguard on and dumped into RogueWave (we're using StlPort or so we thought).
That is suspicious. Do you have RogueWave stuff on your machine? Maybe you aren't
building with what you think you are using.
Quote
That one was on QC3581 2/20/2003
(this time, we changed the code as it's not clear where the problem actually is)

At this point, I can't use Codeguard without the bad cast errors intermittently popping up (
right before the winhelpviewer memory leak which is BTW also on QC4152 4/18/2003)
That would be a pain. I'm using AnsiString rather than std::string and so that might
be the reason I'm missing that problem.
Quote
I have to be careful how I name my files or else the linker gets screwed up. It seems that the
filename
is parsed by the first eight characters so if I have a cpp file called somename.cpp and another
called
somenamemanager.cpp it will matter how they are linked. I don't know if this has been reported to
QC but Chris, Ed and those guys know about this. This kind of sucks when using code from
other departments.
I have almost a dozen files that all start with the first 8 letters but so far have
not been hit by this one.
Quote

Then there's the everyday stuff to deal with like the screwey ctor/dtor order from delphi
that can cause some bizarre results. The fact that the dtor of the main form doesn't
get called when a windows user logs off (thanks to Remy's help we traced this and I
had to add some watchdog disable code to onclosequery() event)

I have to say that most of the IDE bugs seemed to go away after I removed the class explorer. It
seems better than BCB5.

I spent a week or so trying to import one of my projects into CBX. I got it to almost work
but got stuck with the merge/linker bug. I reported a couple of bugs to QC. Both are opened.







 

{smallsort}

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
>On a daily basis I have to deal with the build stopping at the first rc file problem.
>(Reported on QC2072 8/11/2002- one of the highest voted )

How do you get a build working again when that happens? I haven't seen that problem yet.
Add an rc file to your project. The build will stop after compiling the first one. It will not give
you an error. You make think that you've actually built successfully.
For all of the normal projects, we've replaced the rc files (we use dozens)
with the res files. This sucks though as you have to make sure that the rc files are kept up to
date. For the resource dll projects it's more interesting though.
Quote
>Recently I spent 3 days looking for a problem where creating a std::string caused a std::bad_cast
>exception. I found a similar report on QC 2050 8/9/2002 I can either change my code
>(which is correct IMO) or stop using codeguard.

I'd change my code rather than give up on CodeGuard.
It's important to be able to use codeguard but ...
Quote
>
>Before that, there was the problem with trying to use placement new/delete with nothrow. Crashed
>with codeguard on and dumped into RogueWave (we're using StlPort or so we thought).

That is suspicious. Do you have RogueWave stuff on your machine? Maybe you aren't
building with what you think you are using.

>That one was on QC3581 2/20/2003
>(this time, we changed the code as it's not clear where the problem actually is)
BCB6 has RogueWave. Look for old/stlport. As I said, check the QC report.
Quote
>At this point, I can't use Codeguard without the bad cast errors intermittently popping up (
>right before the winhelpviewer memory leak which is BTW also on QC4152 4/18/2003)

That would be a pain. I'm using AnsiString rather than std::string and so that might
be the reason I'm missing that problem.
With BCB5 we changed to AnsiString/TStringList stuff because of these things but we are currently
separating all of the GUI code from straight c++ code. The straight code is not allowed to use
vcl stuff. We need to be able to share classes with our Unix group. Plus with the latest Borland vision,
it doesn't look like we'll be using VCL much longer anyway.
Quote
I have almost a dozen files that all start with the first 8 letters but so far have
not been hit by this one.
It's a problem when one uses the other and is linked before.
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
... On a daily basis I have to deal with the build stopping at
the first rc file problem. ...
Same problem every day - ouch! Add the *.res file to the project
instead of the *.rc file.
Quote
,,, the filename is parsed by the first eight characters so if
I have a cpp file called somename.cpp and another called
somenamemanager.cpp it will matter how they are linked.
I don't know if this has been reported to QC but Chris, Ed
and those guys know about this. ...
You can get bit by an ambiguity by doing header files in a way
something like that but I have not heard of a problem like that for
source files, *.cpp files.
. Ed
Quote
Duane Hebert wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
>On a daily basis I have to deal with the build stopping at the first rc
file problem.
>(Reported on QC2072 8/11/2002- one of the highest voted )

How do you get a build working again when that happens? I haven't seen
that problem yet.
I've "solved" it by doing only makes from the IDE and setting
up a command-line build system with a batch file.
Frederik.
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
>... On a daily basis I have to deal with the build stopping at
>the first rc file problem. ...

Same problem every day - ouch! Add the *.res file to the project
instead of the *.rc file.
That's what I do, but I still have to deal with it every day. We have translators
creating the rc files. When I do a new build, I have to make sure that the res
files are compiled with the latest rc files. I have to check the timestamps on both.
Without this bug, I could just add the rc files and forget about it.
We also generate language dlls from the resource files. This is extrememely
amusing but we only do this once a week or so.
Whatever the workaround/kluge to get this to work, it seems like a simple thing for
Borland to have fixed. It is one of the highest voted QC reports so it's not just
me.
Quote
You can get bit by an ambiguity by doing header files in a way
something like that but I have not heard of a problem like that for
source files, *.cpp files.
But the include order is affected by the order that the cpp files are
called in the linker. Either way, it's another annoying bug that should
have been easy enough to fix.
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

FYI: I've no goal of being an apologist for the compiler Duane. I just try
to help people get up and running with their programs.
You might try something like this:
Investigate creating a new target type, a type with a unique file extension.
Then exploit it to handle the *.res file creation.
For instance (and I've just made this up, "off the cuff" so to speak)
pick extensions of RC1 and RSZ
provide a translator that creates an RSZ from a RC1 by doing
something like this:
brcc32 -ic:\progra~1\borland\cbuild~1\include name.rc1
copy /v name.rc1 name.res
add name.rcz files to the project
Then supply the *.rc files as *.rc1 files.
Something along this line might also be able to handle your issues with
language files.
You might look at the Borland Developer Network site and its CodeCentral
area to get some idea of what people have posted with regard to translators
bdn.borland.com/
. Ed
Quote
Duane Hebert wrote in message
news:40095167$ XXXX@XXXXX.COM ...

That's what I do, but I still have to deal with it every day. We
have translators creating the rc files. When I do a new build,
I have to make sure that the res files are compiled with the
latest rc files. I have to check the timestamps on both.
Without this bug, I could just add the rc files and forget
about it.

We also generate language dlls from the resource files.
This is extrememely amusing but we only do this once a
week or so.

Whatever the workaround/kluge to get this to work, it
seems like a simple thing for Borland to have fixed. It
is one of the highest voted QC reports so it's not just
me.
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
FYI: I've no goal of being an apologist for the compiler Duane. I just try
to help people get up and running with their programs.
I'm sorry if you got the impression that I said anything remotely like
that Ed. I certainly didn't intend to. You've been most helpful here
and I wouldn't want to imply anything different.
I've got my own kluge's/ workaround / gotcha list for BCB. I just commented
that it was getting too large. The OP asked me what my complaints were and
I listed several bugs that have been reported and never fixed.
As for the resource thing, it's really a two fold problem. The first thing is
the workarounds to use the resource files (I'll look into the one you
suggested). The other is the fact that if I add an rc file to my project and
do a build, the build stops after the first rc file. It doesn't report an error.
It doesn't list the time of the build, but other than that, there's no indication
that your exe file has not been changed.
For a while, I was deleting the exe file before building and sure enough, if I
didn't do make after the build, there was no file there.
The first time that I noticed this problem, I was doing some work on an update.
I was debugging and when done, I changed to release build and clicked build.
I ran the exe file on my desk to make sure there was nothing amiss. It seemed
OK. I emailed the file to my startup guy in Germany. I got an email back the next
day asking me where he could get the missing dlls (It was still the codeguard build)
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
I'm sorry if you got the impression that I said anything
remotely like that Ed. I certainly didn't intend to.
No need for an apology. I thought that you were annoyed at me.
Quote
As for the resource thing, it's really a two fold problem. The first
thing is the workarounds to use the resource files (I'll look into
the one you suggested). The other is the fact that if I add an
rc file to my project and do a build, the build stops after the first
rc file. It doesn't report an error. It doesn't list the time of the
build, but other than that, there's no indication that your exe
file has not been changed.
My suggestion was intended to address both of those issues by removing the
listing of an RC in the project
There is one other quirk in the IDE that might be part of what is biting
you. Each project by default gets a newly generated ProjectName.RES file.
If you name your resource file with a base file name of that of the project
then the default resource file of that name will destroy your same-name
file, usually resulting in symptoms that are most odd.
. Ed
Quote
Duane Hebert wrote in message
news:400971bf$ XXXX@XXXXX.COM ...
 

Re:Your biggest BCB complaints? (was Re: cpp_open_letter email address)

Quote
No need for an apology. I thought that you were annoyed at me.
Not even a little :-)
Quote
My suggestion was intended to address both of those issues by removing the
listing of an RC in the project
It seems like that should work. I'm going to look at it on Monday.
Quote
There is one other quirk in the IDE that might be part of what is biting
you. Each project by default gets a newly generated ProjectName.RES file.
If you name your resource file with a base file name of that of the project
then the default resource file of that name will destroy your same-name
file, usually resulting in symptoms that are most odd.
Yep. I know about that already. I've also had problems with my project icon
not working. I've found that I can usually edit the bpr file and remove the
projectname.res file, open the project, add my icon in the project options
and it's back.
Have you had a look at CBX? If so, and if you can comment, what's your
impression?