Roger Cigol

It's a definite personal strength to be aware of one's own weaknesses...

I've brought a few "Classic" 32 bit VCL apps over to "Clang32". Most of the issues are related to poor code by me (often code that I wrote 30 years ago and would definitely not write now!). So in this sense whilst it is an inconvenience it is actually a good thing - it is making the code base more reliable and more maintainable. Of course I don't know what your apps do and what 3rd party components they use so the same experience may or may not apply in your case. Equally I have one set of code that is still a significant source of income for me that is based on "Classic" (again 32bit VCL). With this one I am just starting to look at changing over straight to a 64bit app using the "modern" clang64 tool set. I think I am saying (!!) that you just need to give it a go and see how you get on. You'll know within a day or two whether it's a mamouth task or a relatively straightforward one.

BDE is deprecated. It's still available but it's definitely "had it's day". Not essential - but really the only sensible thing to do. I used BDE for one project and found the upgrade to FireDAC not that difficult to do. Can't comment on how much of a task it will be for your project though !

If you stay with "Classic" you are staying with an obsolete platform. It is likely to be around for years and years to come (because of so much legacy code out there) but it is no longer under any further development; each new version of RAD Studio or C++ Builder comes with exactly the same "Classic" compiler. Staying with "Classic" also ties you to 32 bit only application. It's not my job to explain all the advances in C++ syntax and the associated STL additions that have happened since the days of the "Classic" compiler - but there are many many many in the list. As soon as you start using Clang you don't want to go back to "Classic". If you are not so familiar with modern C++ start by reading the latest edition of Stroustup's "A Tour of C++" and see how many things in this (fairly brief) text are new to you. Scott Meyer's "Effective Modern C++" is another good book. There are hundreds out there.. There is one disadvantage of the Clang compiler: It's compile times are slower. Make sure you use the TwineCompile plug in (free of charge on Getit package manager). As an upgrade path I would suggest make the change to 12.2 staying with the "Classic" and once you have all your other issues solved then move to Clang.

Hi @shun Sorry for delay - busy week.... Up to date feature matrix is here: https://www.embarcadero.com/products/rad-studio/features/feature-matrix According to this site https://plaza.kpt.co.id/IT/en/107-2/Embarcadero-Delphi_8137_plaza-kpt.html Delphi / C++ Builder 5 dates from 1999 - so you are looking for a feature matrix 25 years old (if it ever existed). Fifteen minutes on google has not yielded a hit for this but you might do better.....

Did C++ Builder 5 default to storing the *.dfm files in a binary format ? If this is the case then the above advice won't work.

Does your C++ Builder 5 use any features that are "Enterprise" edition only? if so you would need to make sure you have access to these in the Trial edition. C++ Builder 5 used String = AnsiString - all modern editions use String = UnicodeString. This can be need a bit of work if you are using low level processing of the String types. Often this change is hardly noticed. You would need to decide if you are going to stick with the "Classic" compiler (which does still come with 12.2) or move to the Clang compiler which immediately gives you access to modern C++ constructs but can also highlight non-standard (ie not quite standard) coding practices that worked under the classic compiler but don't work with modern C++. My view is that it's worth the effort to move to the modern tool chain.

Very good suggestion by @dummzeuch Very few people give enough thought to naming of functions and variables. Developing a consistent approach can significantly help with long term program readability / long term support for large projects. Anything that hints at doing that gets my full support ! https://cigolblog.wordpress.com/2023/01/ https://cigolblog.wordpress.com/2019/10/ https://cigolblog.wordpress.com/2017/06/

It seems as if the current system allows people to make posts as either "private" (in which case no one else can see them) or "public". https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-1987 was originally a "private" posting but has been made "public". @Gord P you should be able to view this now....

@alank2I now do have access to the RSS and have updated the posting thread with my confirmation of the issue.

I can't find this RSS report at https://embt.atlassian.net/ - Are you sure it got entered correctly? Can you post a URL to in this thread please?

I can confirm that I get the same problem as you (RSS-1987). I get the same issue if I compile with TwineCompile. @Jirka52This is what you would expect - it's not a compile time error - it is a debugger issue. If you get a compile time error there must be a problem with your source file. (or something else strange). I also get the same issue if I add a line: String S = _D("μ \u00B5 α Ω °C © Å "); and then save the file - this forces the file encoding to be UTF-8 with a BOM identifier. Definitely a bug. What is interesting is that the IDE works fine with target of Win64 (traditional) or Win64 (modern). What is interesting and surprising is that the IDE hangs in the same bad way if you use the Win32 classic compiler.

Tiny and easy work around maybe - but still worthy of reporting. That way there's a chance it will be fixed in a later release. Small improvements help make the tool set better for seasoned users and new users alike. Out of interest: 12.2 does include a minor fix that I reported so it is worth doing !

Thanks @David P. Yes, you do need to recompile with the \win64x output directory. All is good now - thank you for your extra explanation. Thanks too to @Uwe Raabefor his help / clarification.

Yes, you can compile them of course. But not with the clang C++ compiler. Under the hood the C++ Builder (or RAD Studio) uses the pascal / delphi compiler to compile the *.pas files.

For the benefit of me and other interested parties can you expand on this please? Delphi components implies they are written in Delphi. You can't compile these with any of the C++ compilers..... So what exactly did you do that made the third party component work in your case ?

I've been using C++ with VCL since the early 1990s and still think it's the easiest way to write C++ GUI windows apps.

This page lists the different debuggers https://docwiki.embarcadero.com/RADStudio/Athens/en/Debugging_Multi-Device_Applications Have you tried selecting the "classic" compiler? - this will (I think) debug into the VCL.

This is related to the different debugger technology in use for Delphi and the different C++ compilers. This is unlikely to change between 12.1 and 12.2 (it would be a big change to change the debugger for a particular compiler - not one that would normally be done as as a same version upgrade). I am sure there is another posting on delphi-praxis covering exactly this issue - but I must admit I spent five minutes looking and couldn't find it.

it's difficult for Embarcadero to fix if it's related to a third party tool. Do you have third party tool(s) installed ?

Do you have an XML Schema file (typically file extention = .xsd) for the UBL 2.1 model invoice? If so you can use this with XML Mapper to generate a transform (at design time) which you then use in code so that it can populate a client dataset (at run time) with data from an incoming XML file. With this approach XML files that only contain partial amounts of data (as you anticipate) are handled correctly.

Are you aware of the XML mapper tool?

I have a working class to interface to a COM interface (created by a 3rd party). My working class is a wrapper around the type library functions I generated using C++ Builder. This code works 100% when compiled under C++ Builder 10.4. I have just used the same class in a new application running on the same machine as the working system but this time compiled using 11.2 patch 1. This doesn't work. The problem seems to be in passing pointers to BSTR. I use WideString.c_bstr() to get the pointer to the BSTR to pass to the COM interface. QUESTION: can anyone confirm that this approach works ok using 11.2 ? (or should I be looking into this at a lower level with a view to creating an Embarcadero RSP bug report?)

or write a function that checks if your text ends with a ';' character and if so deletes the ';' character. Then use a global search for each time you set the SQL property of the query and surround each text with a call to your new function.....

...Also: which compiler are you using. C++ "classic" is the 32 bit compiler developed by Borland but basically frozen quite some number of years ago. The recommended compilers are Clang32 for 32 bit targets and Clang64 for 64bit targets. 12.1 also introduced a new tool chain for clang 64bit which is expected to replace the earlier 64bit system (this is currently called clang64 modern) but in 12.1 it has some minor limitations which may make it not your first choice if you are still finding your way around. These limitations are understood by Embarcadero and are expected to be removed in next version or two with the goal being to replace the clang64 approach with this "clang 64 modern" approach. You select the compiler used for 32 bit applications using the menu Project | Options and then under Builiding | C++ compiler there is an entry "Use classic borland compiler" (I suggest you set this to "false"). You select the compiler used for 64 bit applications using the "target platform" in the project tree.