C++ 5.0 OWL Conversion to Builder\MFC ??
Paul Gordon
when OWL was still the best choice ) .. where do we go from here? What has
it been like converting to Builder? Or should we ditch borland and go for
MFC? How is Builder as a development Environment for OWL Code? Are there
any Conversion tools for Builder\MFC etc ( even if they only do part of the
job )? Also if we are to move on the future needs to be considered ... what
happens in 2 years when Inprise decides to ditch Builder for something
completely different. I have been loyal to Borland products for years ..
but they don't repay that loyalty .. is it time to move on? I know there is
an OWL 6.0 but I don't consider that a serious option for the future.
Another reason for thinking of moving to Visual C++ is the quality of
support from microsoft products with the EXCELLENT MSDN and the sheer number
of people out there that are working with the products leading to plenty of
support information on the net. I think the situation is better with
Builder .. but I seem to have to blindly try to solve most of my problems
dealing with bugs in Borland products through lack of documentation ( or
wrong documentation ) or trying to add some new feature relying on the
Minimal documentation provided or the Examples which ussually add no value
whatsoever. Whats the level of documentation and support like with
Builder?? Is it a lot better than with C++ 5.0 etc.?
Thanks for any insights you can provide,
Paul Gordon.
ShortCuts.
Rob Allen
>We have a project that has been developed over 5 years in OWL ( started back
>when OWL was still the best choice ) .. where do we go from here? What has
>it been like converting to Builder? Or should we ditch borland and go for
>MFC?
[SNIP]
We're in a similar boat. I don't know the answer unfortunately. I've
tended to find peer support in newsgroups/mailing lists as the best
help I'm going to get. I know that the borland C++Builder groups
contain some very knowledgable, helpful _and friendly_ people, but
have no idea what the Microsoft equivalent is like.
Rob...
--
Rob Allen
My opinions are my own and mine alone!
Correct email: rob (at) freshfieldcom.com
Alex Bakaev [TeamB]
workshop ), but this can be done.
Also, tt has an .rc import tool that will convert dialogs into forms if
you want to switch to VCL/RAD type of development. I'd say give it a try
and if it doesn't work out for you after a few weeks, return it for full
refund.
Alex
Paul Gordon wrote:
>
> We have a project that has been developed over 5 years in OWL ( started back
> when OWL was still the best choice ) .. where do we go from here? What has
> it been like converting to Builder? Or should we ditch borland and go for
Greg Chicares
I believe I'll forsake all proprietary software. Here's the
new toolset I'm thinking of:
compiler: egcs
IDE: RHIDE
framework: wxWindows
I'm very certain about the compiler and less certain about
the rest. I share your concern about the future of Builder
given the history of OWL. I would never choose MS tools.
Jonathan Schafer
although it's a beastly hog. But, tons of functionality Borland never
had. I like Borland for other reasons, OWL being the biggest one.
Has anyone noticed that MS seems to be paying a lot more attention to
Linux these days. I think they are actually a bit afraid that it might
just take off. Given the recent investment in Red Hat by Intel, and the
Java problems MS has, MS might have it's own Y2K problems, but they
won't be date related.
Jonathan Schafer
Paul Gordon
Alex Bakaev [TeamB] wrote in message <3613D8A3...@jetsuite.com>...
>BCB isn't as good as BC++ for OWL development ( no experts and resource
>workshop ), but this can be done.
>
>Also, tt has an .rc import tool that will convert dialogs into forms if
>you want to switch to VCL/RAD type of development. I'd say give it a try
>and if it doesn't work out for you after a few weeks, return it for full
>refund.
>
>Alex
Thanks Alex,
We have never used the Experts and do not rely heavily on Resources ... Are
there any other disadvantages ? Also, what is tt ?
Paul.
Benny Bula
Because they are better , hehe ?
Joe Snow [Team A]
dropped by Inprice in a couple of years.
Alex Bakaev [TeamB]
a different kind of tool. You may consider lack of 16 bit/DOS support a
disadvantage.
Alex
Mark Jordan
> I like Borland for other reasons, OWL being the biggest one.
Yeah,
That was my biggest reason for using Borland too. Now that they
have abandoned OWL, I'll probably abandon Borland.
I've developed commercial applications with MFC, IBM's OpenClass
library and OWL, and I can say that out of these three, OWL was by
far the nicest to program in. IBM's OpenClass comes a close second,
and of course that war pig MFC comes last.
Cheers,
Mark Jordan.
Pete Fraser
builder it opens their eyes. Give it a try - it makes the object oriented
thing more visual and after a week using it - well I love it now.
Rgds Pete
Jonathan Schafer
boxes and property sheets more visual, sure, I'll agree with you. But
it does absolutely nothing for OO and class design. And since 80%+ is
the usual amount of non-gui work for an application (excluding non-corp
db access apps), it doesn't save you near as much as you think. Yes,
you can have prototypes up with all your UI elements much quicker, but
the meat of the program will not be affected by any visual design mode.
Jonathan Schafer
Alex Bakaev [TeamB]
> the meat of the program will not be affected by any visual design mode.
Then, there is no reason to switch to VC++, right ? Meat of the code
will be the same, not matter OWL, VCL, MFC.
Alex
Jonathan Schafer
BC++ dead and OWL more dead, there would be no more updates to the UI
features we do use. Plus, given the difficulty of getting libs linked
with Borland when the rest of the world uses VC, it wasn't worth the
hassle. The program I am currently working on has over 2500 classes.
Less than 50 are UI related. It has full OLE automation, ATL
subprojects, 3rd party tools, and more all mixed together. To build it,
I press 1 button and walk away for 30 minutes. I don't think I'd have
that kind of luck with BCB and even BC++ wouldn't be so kind.
Jonathan Schafer
do not reply to my spamtrap
>Then, there is no reason to switch to VC++, right ? Meat of the code
No reason at all. Unless, of course, you want a current product that will be
available for a while. I would have preferred that Borl^^^^Inprise beef up the
lame IDE they wrapped around OWL instead of just abandoning it like they did TV,
OV, and OWL for OS/2. Three years from now, even assuming they're still in
business, VCL will also be unsupported history, going by their track record.
All the folks who stuck with Borl^^^^Inprise and made the transitions from TV to
OWL to VCL will have yet another major transition to make.
As for the next version of VC++, the folks who are using MFC will have to...
re-compile and re-link.
--
The true scientist revises his beliefs to fit the evidence.
The true believer revises the evidence to fit his beliefs.
--
hlh_N...@mailexcite.com is a valid address. It is NOT munged.
However, it is not read, either. Please reply via this newsgroup.
Michael Aubermann
But which compiler will you use instead?Enjoy,
Michael.
Leo Siefert
>
> How can it make OO more visual?
Has anyone here looked at Together C++ (Design Tools) ? This _does_
make OO visual. I haven't decided yet whether or not it speeds
development (or slows it), but it gives an interesting view of the
project.
Is anything like this available in any of the other C++ products (at
less than an enterprise-level price) ?
- Leo
Dany Marmur
>
> We have a project that has been developed over 5 years in OWL ( started back
> when OWL was still the best choice ) .. where do we go from here? What has
> it been like converting to Builder?
Well. OWL does compile in Builder. It's a little bit slower. Exception
handling work a little bit better (which is my main reason for
upgrading). The compiler seems (this is just a feeling) to work a little
bit better. Incremental linking has become available to me only with
Builder as I use BDE, that is a lot faster. Now to the specifics, taken
bigger projects:
The little page in the Builder help about converting does not all of
what's have to be done. This is my bumpy road to an executable (whitch
did grow a little bit in size).
1. The IDEtoBPR did not work at all for me. I tried all the
recomendations. I had to build the "project tree" from scratch. Not very
difficult when you've dug into it. Builders project management is
nothing compared to BC++ but it can be made to serve at a basic level.
2. The BIDS strings and BIDS streams seems impossible to use in builder.
This has something to do with the RTL. All calls of strign::contains,
string::strip, string::ansi_to_oem (and vice versa) had to be switched
to STL notation. Also NPOS is now string::npos but such things can be
#defined. Maybe I'm ignorant but I had to switch from << setprecision()
<< to .precision() with streams.
3. Some definitions of recources must be twiggled a bit.
4. You'll have to check the examples and get a good idea of the Builder
project file. It can be edited directly and probably has to be. The
on-line help has a good table of which libraries you should use. I did
not try to mix VCL and OWL, though.
5. Big problems with BDE. The BDE SDK, that is idapi.h and idapi32.lib,
is dead. idapi32.lib can not be used as Builder only links incrementally
from the IDE. I tried tlink32 but never got it to work. The big problem
with bde.hpp is that it included some headers. This forces you to use
namespaces for all OWL classes that clash with the classes in those
headers. Theese where for example TRect, TSize, TPoint, TBitmap. I
finally decided to specify those classes (OWL::TBitmap) as namespaces
can be tricky when headers are included into them. Another thing was my
own module layout. bde.hpp automatically includes a lot more than
idapi.h so I was forced to rearrange databas-GUI relations. Mainly
because the relation was a little stiff from the beginning. Bde.hpp is
also a C++ header using references where idapi.h user pointers for
output. It's somehow taken from pascal (?) so the C function syntax in
bde.hlp is no longer correct. Although bde.hpp will compile cleaner with
less conversion warnings.
6. cm32mt.lib GPFs when cleaning up STL strings as members of classes
used in BIDS containers. use cp32mt.lib. Only 50K code bloat.
7. STL strings seems slower than BIDS but I haven't dug into initial
capacity and stuff yet so I might be able to trim it.
Most stuff will be warnings and/or errors. Temporaries used in BDE calls
are dangerous. When BDE switch from unsigned to signed int for some
counters you'll have to change output formatting of theese numers. Some
old workarounds can create havoc. For example BIDS string
find_last_not_of had a bug returning string::length()+1 for noting "not
found" and an old workaround can become a bug when the new class returns
npos.
It was a lot more work than I liked to do, but now it's done.
/Dany
Rob Allen
Dany Marmur wrote:
> Paul Gordon wrote:
> >
> > We have a project that has been developed over 5 years in OWL ( started back
> > when OWL was still the best choice ) .. where do we go from here? What has
> > it been like converting to Builder?
> [snip]
>
> Well. OWL does compile in Builder. It's a little bit slower. Exception
> handling work a little bit better (which is my main reason for
> upgrading). The compiler seems (this is just a feeling) to work a little
> bit better. Incremental linking has become available to me only with
> Builder as I use BDE, that is a lot faster. Now to the specifics, taken
> bigger projects:
>
> The little page in the Builder help about converting does not all of
> what's have to be done. This is my bumpy road to an executable (whitch
> did grow a little bit in size).
>
[snip]
I've had similar experiences, although I don't use the BDE so have no exeperience
there.
The biggest problem that I found is that compiling an OWL property sheet in
Builder will
not work on plain vanilla win95, but a BC5 version of the same code will! The
Builder
problem can be solved by putting on IE4 and may be solved with the "40Comupd.exe"
common control update from MS, but I haven't tried that option yet.
Rob...
--
My opinions are my own.
Dany Marmur
That sounds alarming. If you have the time, could you just scribble down
some specifics. "If there can be a problem, there will" is some law I
heard about :) So it's always good to be prepared.
/Dany
Rob Allen wrote:
>
> Dany Marmur wrote:
>
> > Paul Gordon wrote:
> > >
[You've read it all already]
Rob Allen
Dany Marmur wrote:
> Rob!
>
> That sounds alarming. If you have the time, could you just scribble down
> some specifics. "If there can be a problem, there will" is some law I
> heard about :) So it's always good to be prepared.
>
> /Dany
>
[We're talking about OWL::TPropertySheet in BCB3]
Take one copy of BCB3 and install with OWL support. Find the
"BCB3\Examples\OWlFiles\Owl\Apps\Blazer" example and compile in BCB3.
This is a greate little example program that shows many things. One of the
things it shows is TPropertyPage/Sheet in the Help|About dialog box by
pressing
the "Options" button.
Take your executable that you've just created an run it on Win95, Win95a,
Win95b
and Win98. It will work in Win98 and I can't remember what happens in
Win95b.
Now install IE4 onto the various flavours of Win95 and see the options page
start
working!
Now we have exactly the same sample app in "BC5\examples\owl\apps\blazer".
If
you compile this version in BC5.02 and run it on win95 et al, it will work
on all of
them without any problem. The obvious question is "what changed?" but I
haven't
been able to work that one out yet. What I haven't had time to try yet is
the common
control update from MS. This may solve the problem and wouldn't mean having
to
install IE4.
HTH
Rob...
(BTW, I'm away on business next week so don't think that I'm ignoring any
responses!)
--
Rob Allen
My opinions are mine and mine alone!