Roger Cigol

WP tools: https://www.wpcubed.com/pdf/products/ I agree with @Angus Robertson - it's not clear why you posted your question under ICS. You might get an answer on this (DelphiPraxis) forum but maybe you would be better posting it on the WP forum: https://www.wpcubed.com/forum/board/

Where are you geographically speaking on the planet?

There is now a "whats coming in RAD Studio 13" webinar (10th Sept). Sign up here: https://register.gotowebinar.com/register/8824728052527544667?source=rad-update-blog

Added support for Linux by rewriting ±769,000 lines of Windows-specific code Built a unit testing framework from scratch (500+ tests) A code base with towards 700 000 lines of windows specific code presumably has much more that is not "windows specific". To then claim that 500 unit tests is useful strikes me as a sentence aimed at people who have never worked with unit testing. Even my simplest projects have unit tests measured in thousands.....

Does this statement apply to Clang32 compiler ? I believe your statement to (in general) be the case for clang64 but am less sure it applies to clang32.

Are you using TwineCompile ? - for the 32 bit clang compiler this additional plug in (available FOC on getit) is virtually essential.

I agree entirely with @Michaell However there actually are often good reasons to switch, common ones are any of: a) you want to write 64bit applications b) you want to use any of the modern C++ features (for example the use of "auto" is often really useful (aka essential) for templates) c) you want to use any modern C++ library (most up to date versions of libraries fail to compile on "Classic") d) you employ a young C++ programmer who finds it frustrating to work with "Classic", having got used to working with modern C++ constructs available. For any project with a long term future there is likely to come a time where you will want to change to Clang. The compilation time is a real pain! But you learn to structure your code such that a full build of all files is not required so often. (There is also the "module" approach coming to C++ bit by bit which is claimed to speed up compilation, but that is very definitely another topic!). I have moved most of my main projects across to Clang. I have one more commercial project to migrate and am just waiting for the right moment (which is related more to commercial and administrative considerations rather than technical ones).

Good morning @Michaell I will be honest: All of my projects used by customers are either Win 32 VCL using the Classic compiler (ie the old established projects) or Win 64 VCL using the "modern" clang compiler. So actually I have little "working" experience with the Clang 32 bit compiler. When I have upgraded a project from Classic I have gone first to the clang 32 compiler and then on to the Clang 64 "modern" compiler. I don't recall any migration being a real headache - although it's never a simple rebuild without doing anything ! I have today used RAD Studio 12.3 Enterprise to create a brand new C++ VCL 32 bit project. This uses a single form. It uses TEdit, TButton etc and also some of my own VCL components (which are written in C++ and are installed into the ide at design time). I use static linking for all packages, for the delphi run time and the delphi run time library (I do this for all projects I ship - I do recall in the past finding issues with my own components when I try to link at run time). I now have a working project. I can change between "Classic" and "Clang32" simply by selecting which compiler in the project options C++ compiler check box. The only other thing I have to do is manually change the library path to point to the directory with my *.lib file that contains the code for my own components (I have two builds of this - one done using the Classic and one done using the Clang32 <both have the same extension *.lib so I put them in different directories> - if I don't do this the project compiles ok but the linker reports loads of warnings saying that the library is built with the wrong compiler. I don't have any settings in the "additional options to pass to the compiler". I do have to do a full rebuild each time I swap the compiler type (completely reasonable!). All my source code, including the project file is in D:\Projects\Cigol quick test scratch\c code x For both cases the object code is output in D:\Projects\Cigol quick test scratch\c code x\Win32\Debug For both cases the object code files have a *.obj extension I think this only applies to the Clang 64 bit compilers

It should compile with no additional options specified by the user - what do you see in this box ?

In all my projects I have NO entries in the "Additional compiler options" So if you have something there and you don't know what it is I would suggest try deleting it.

OK - I don't know if I qualify for your definition of "experienced user". But I am trying to help. By solving these sorts or problems we all become more experienced. But there is always more to learn (which is what makes life worth living). Please do check that you have no unexpected entries in "Additional options to pass to the compiler". Another thing to check is that you the object files are being created where you want them to be. Check project options: C++ Shared options | Intermediate output.

I do recall (vaguely) once having to remove a load of options that were being passed to the clang compiler, without ever understanding where these options had come from. You need to check that there are no additional options being passed. Project options section: C++ Compiler | Advanced | Other options | Additional options to pass to the compiler

This is strange: I have not seen this issue before when migrating from Classic to Clang32. What version of C++ Builder / RAD Studio are you using?

Which compiler are you using? (Classic, Clang32 or Clang64) ? Try changing compiler and see if you get a different behaviour (I know this may not be a fix but it may be useful to know).

But don;t worry (unless you also have delphi projects), C++ projects that use 3rd party components that happen to be written using Delphi will work just fine. C++ with the VCL or Firemonkey works fine too. Which ompiler to use depends on your aims for the upgrade. Does the original project use the 32 bit "classic" compiler? if so then for the first stage of the upgrade I would suggest continuing to do so. In my experience you will have very little problems (usual no problems) with this change

It was so long ago when I first used it. But I am sure it's easy to do. The script system is straightforward and there's lots of help out there. My install operations are not complicated though (just exe, dll, desk top short cuts etc).

I also use InnoSetup - and I use C++ for many many projects (12.3 Athens)

I can see a sample .gitignore file for Delphi at https://github.com/Embarcadero/RADStudio11Demos. But I can't find an equivalent for Embarcadero C++ projects. Does anyone know of one up there (or anywhere else) (and is it up to date to include ignoring the _astcache folder contents)?

Can you run your project under the debugger, then put a breakpoint on the button press and then single step into the code that shows the form. That will bring the form .pas (and .dfm) into the IDE

It's called the April patch - but it's out now ! https://blogs.embarcadero.com/rad-studio-12-3-april-patch-available/

Me too: Got here because of the same issue - and also was really annoyed by this too ! Many thanks to @peardox

The delphi components are all available from the component pallet. This is reasonably well organised into groups which give a good indication of the type of functions provided by each set. Best way to learn is to create an empty form and put the component on it. This brings up all the properties (again most are self explanatory (at least for the commonly used components)). If you go to the corresponding source code and click so the cursor is in the component name and then use F1 this will bring up "help" documentation. For more (better?) help - you can search for the component in the DocWiki https://docwiki.embarcadero.com/RADStudio/Athens/en/Main_Page By the way - you did post your "Delphi" related question in the C++ section of the forum - perhaps not the best place to reach other delphi developers (although all the VCL components can be used with C++ too).

This strikes me as being a classic use case for inheritence. Define a base class of a type ObjectToStoreInStringGrid and then derive each of the types you need to store from this base class.

Closing a query does not close the corresponding database connection (this applies both if it is pooled connection or not pooled)

Hi @MrBlues I do wonder if you might have been better posting your question as a brand new topic rather than adding it on the end of a year old and only partially related post. Not to worry.... It is always better to start with a *.xsd schema file rather than an *.xml data file when creating transformations. The schema can (and usually does) contain more information about fields. However not every use case allows this (a schema may not exist or may not be available) and XML mapper is designed to work when you start with an XML data file (as you have done) The main purpose of XML mapper is as a design tool. You create a dataset mapping and from this you create a transform file *.xtr, The normal case is then to forget about XML mapper and just take your transform file and use this at run time in your Delphi (or C++) application. If you load the transform file back into XML mapper it does not contain any data and you get the blank fields (exactly as you have described). There are (rare?) cases where you want to load in the *.xtr transform file back into XML mapper (perhaps if you want to edit it, for example). To do this you need to store a copy of the original XML data file in with the transform file, at the time the transform file was created. This usually results in a much larger transform file and this "file size bloat" serves no purpose when the transform is used at run time in a Delphi or C++ app. For this reason XML mapper now has a check box that must be selected (before the transform file is created) that forces XML mapper to include the XML data file in the transform file. You can see this check box (called "Incl. XML Schema" on your first screen shot, towards the bottom left of the middle section of XML mapper. BACKGROUND: Earlier versions of XML mapper did not have this check box and always added the XML data to the transform file.