Page 1 of 1

Project conversion

PostPosted: Thu Apr 04, 2019 12:56 am
by rajesh
Is there any way to convert Borland C++ builder 6 project to Embarcadero® C++Builder 10.3

Re: Project conversion

PostPosted: Thu Apr 04, 2019 5:04 am
by 2ffat
It may depend on the libraries you used in BCB 6. I have successfully rebuild BCB 6 programs for Builder 10.3 but I had made sure that the original programming was compliant with Windows protocols. If you used any third party libraries then you will need to make sure those are either compatible or updated to 10.3. That's probably the biggest problem I've seen.

At worst, I created a new project in 10.x, then copied the functions from the original project into the new one.

Re: Project conversion

PostPosted: Thu Apr 04, 2019 11:43 pm
by rajesh
I had Simply C++ Builder 6 Form Project , Even it is not loading in the version 10,3

Re: Project conversion

PostPosted: Fri Apr 05, 2019 2:27 am
by smd
rajesh wrote:I had Simply C++ Builder 6 Form Project , Even it is not loading in the version 10,3


I suggest copying your source files to a new directory then re-create the project file from scratch by adding those files into it and setting the various options.

Re: Project conversion

PostPosted: Sat Apr 06, 2019 8:57 pm
by denville
Hi, I still use CPB6 predominantly. I also have XE7 (also obsolete !) which I occasionally use when I need its additional features (such as 64-bit compile, latest IntraWeb).

Moving from CPB 6 to XE7 I have universally found it necessary to follow the plan:
- Create a new 'Hello World' app in XE7
- One by one, add the support units to the project and check each one compiles
- Finally, replace the main form in XE7 with the old Main Form (remember to make it top of the list)
You will almost certainly come across Unicode issues which are well documented. I use a lot of traditional (8-bit) char* and you will have to find a way to get a char* from a Unicode string. Beware the t-str() - apparently it alters the underlying string! I have found the following useful and reliable:

#ifdef UNICODE
static char* C_STR( AnsiString s ) { return s.c_str(); }
static char* C_STR( String s ) { return AnsiString(s).c_str(); }
#else
#define C_STR(s) s.c_str()
#endif

then where appropriate change some_string.c_str() to C_STR(some_string) and it should work in both the Unicode platform and still in CPB6.

One other thing to remember - unfortunately it is not possible to share the same form unit between CPB6 and later versions as the later ones add properties to the form that CPB does not then understand. Bit of a pity that.

Best of luck !

Re: Project conversion

PostPosted: Wed Apr 17, 2019 1:38 pm
by rlebeau
denville wrote:Beware the t-str() - apparently it alters the underlying string!


Only in C++Builder 2009 and 2010, and only if TCHAR maps to 'char'. This was for purposes of helping people migrate legacy Ansi code to Unicode. t_str() was deprecated in XE, and changed to return only wchar_t* to match c_str().

denville wrote:
Code: Select all
static char* C_STR( AnsiString s ) { return s.c_str(); }



That should be taking the AnsiString by reference:

Code: Select all
static char* C_STR( AnsiString &s ) { return s.c_str(); }


denville wrote:
Code: Select all
static char* C_STR( String s ) { return AnsiString(s).c_str(); }



That will not work at all. You are returning a pointer that is owned by a temporary AnsiString that gets destroyed when the function exits, leaving the returned pointer dangling.

Since you would be re-writing code anyway to utilize C_STR(), it would be safer to simply replace some_string.c_str() with AnsiString(some_string).c_str() and be done with it. That will work in all versions, no #ifdef's needed.

denville wrote:One other thing to remember - unfortunately it is not possible to share the same form unit between CPB6 and later versions as the later ones add properties to the form that CPB does not then understand. Bit of a pity that.


There are 3rd party tools to deal with that.