Roger Cigol

"Which is the best way?" questions in C++ are always tricky! The language has evolved so much (and continues to do so). We C++ Builder users have the added complication of the use of the VCL or FireMonkey functions (that come from the Delphi RTL). How important it is to keep your code portable is certainly one question to consider. Re: text files : also take into account encoding possiblities - if you need to anticipate different encodings then the VCL support is often the easiest route. I tend to use TStringList as the store and then the LoadFromFile() and SaveToFile() functions.

Find Symbol works for me - with both clang64 or with classic 32 bit (not tried it with clang32). But I have to actually select the text (typically by dragging over it with the mouse) before using the search ! find symbol

I have a Win64 C++ Builder VCL FireDAC application. I have a TFDQuery that is used as the source for a TBindSourceDB component which in turn is used for livebindings for conveniently displaying the query results on a string grid. With the change from RAD Studio 11 to RAD Studio 12 (patch 1) came the introduction of better support for fields of TimeStamp with offset (timezone) types. With RAD Studio 11 it seems that these were just treated as TimeStamp fields (ie the time zone offset was ignored). Code that worked in RAD Studio 11 stopped working in RAD Studio 12 (patch 1) and I traced the problem to the fact that one of the field definitions for this particular TFDQuery now needed to be changed from type TSQLTimeStamp (which worked in 11.) to TSQLTimeStampOffset (which works in 12-patch 1). The underlying type in the postgreSQL database for this field has always been "time stamp with time zone". I have this all understood and it is all now working following this change of type. MY QUESTION Is there a convenient way to change the TYPE of a field definition through the IDE? I couldn't find a way to do what you would think should be a simple task. In the end I "cut" the query component to the clip board, pasted it into a text editor, changed the type as described above, copied the text editor contents to the clip board and then pasted it back into the VCL data module. Not actually too difficult but hardly what you would expect to have to do in a RAD Studio IDE! I suspect I am missing a trick, hence this appeal for advice.... Attachments: file "Structure.jpg" shows the field (after my change of data type) selected in the structure pane. In the properties pane there are lots of properties, but not (or I couldn't find it!) the field type. "NewField.jpg" shows the "wiard" form that appears if you add a new field to the field definition - here there is a drop down box in which all the possible field types appear and you can pick the one you need. But I can't find a way of getting this box up again for an existing field... (Not sure if this should have been posted under category: IDE, VCL or Database - so I went for "Database").

I don't actually see that you have to do anything here - just don't take any action for the case(s) you want to ignore. If you do want to skip an extra step you can always deliberately increment the counting value - ie use this line inside the loop.... i = i + 1;

Interested in the future? Embarcadero - the future of clang - webinar

Hi @Lajos Juhász Thanks for this. Usually editing techniques apply equally to Delphi or C+. I have the datamodule on the screen. But under my View menu I do not have a "View as text" option (is it somewhere else?). However alt+F12 does indeed change the form view to the text equivalent. Here I can manually edit the field (or anything else!). And alt+F12 toggles it back afterwards. I never knew this short cut (after all these years.....). So this saves me manually cutting and pasting to a different text editor. This may be useful to me in the future. It does still strike me as not being a RAD Studio IDE elegant way to edit a property. I wonder why the field type does not appear in the "properties" pane? I can visualise that there could be a good reason for this but if so it would be much better if a right click on the field in the structure display also gave me an option to bring up a window the same as the "new" field window - where I could then adjust the type. May be I'll put in a feature request when the quality portal comes back from its "holiday"......

I haven't tried this but I would have thought just assigning a text string to the components "hint" property at run time would make it appear.....

Just posting this in case anyone else out there is wasting their time on this..... It seems that there is currently a problem with using the Clang compilers in RAD Studio 12.0 with the GoogleTest framework on getit. The version currently (Jan 2024) available does not build correctly. I will monitor this situation and blog here as soon as Embarcadero have a working GoogleTest framework on getit.

Just to add that I have now repeated this exercise but this time using the Clang32 compiler for unit testing a Windows 32 bit app. All went as expected - no issues.

Hi Ian, May I respectfully suggest that posts with titles such as "Is it just me?" and "-ummmm what" don't help other users of this forum when they may be searching for solutions to the same or similar problems to your posts. Surely the title is intended to be a brief summary of what the post is about. You may get someone reading it who knows the answer if you choose your title correctly.

I have just installed RAD Studio 12.0 path 1 using Getit. It all ran through smoothly - no errors reported. I got the readme displayed at the end with the patch 1 information. My original installation was done from the downloaded RAD Studio 12.0 ISO. I can build a complex VCL C++ 64 bit project - no errors, as before (using TwineCompile). Only problem I have is that the IDE still says "patch available" and the Help | About does not mention the patch 1 upgrade. Note; My installation is a bit unusual in that my original install is to D:\Program Files (x86)\Embarcadero\Studio\23.0 Note; D drive rather than C drive ! Using BeyondCompare on the data obtained by Help | About and then clicking on "Version Information...." does show many newer version numbered files and in my ....\Studio\23.0 installation directory I do have a new directory called _patch-backup which contains all the old files, so I am sure my patch installation has gone in ok. I really like the visual assist integration in C++ for RAD Studio 12.0. It all seems to work well and is a very useful addition to the editing experience.

I have spotted this warning about the patch 1 for C++ users.... Oliver Weinheimer February 8, 2024 at 3:30 am I just installed the patch. I’m a C++ user – couldn’t build my projects with 12.0, when building a package components don’t show up. But this is another story. OK. At least I was able to build test projects with 12.0. Now after the patch, RAD Studio can no longer link a bare C++ VCL project without anything in it for Win64 (Win32 works). For Win64 I get: [ilink64 Error] Fatal: Unable to open file ‘;E:\RADSTUDIO12BETA\JEDI\JCL-MASTER\JCL\LIB\D29\WIN64;C:\USERS\x y\DOCUMENTS\EMBARCADERO\STUDIO\23.0\CATALOGREPOSITORY\JEDICODELIBRARYJCL-2023.11\LIB\D29\WIN64;C:\USERS\PUBLIC\DOCUMENTS\EMBARCADERO\STUDIO\23.0\DCP\WIN64\RELEASE;C:\USERS\PUBLIC\D’ The only thing I did was installing the patch!!! Oliver posted this in the comments section at the bottom of this page https://blogs.embarcadero.com/getit-update-additional-rad-studio-12-getit-packages-are-now-available/

GetIt also looks active for C++ Builder 12.0 as well as Delphi

@Lajos Juhász This solution is only possible when 32 bit drivers are available - and it is not doing what @RDP1974 asked (which was to use 64 bit at design time). In my example of postgreSQL the only 32bit versions are now quite old (I would venture to suggest obsolete).

No - All the IDE is 32 bit. This is a pain when (in my case) I want to work with PostgreSQL as all the more recent versions of PostgreSQL are only available as 64bit servers. So I lose all the (neat and nice) design time execution features of FireDAC. No real way round this (and there is little sign of Embarcadero IDE moving to 64bit in the near future)

Also take a look at Supremo - this is remote desktop software that is very simple to configure and use. It is also, I believe, written in Delphi. License fee is very competitive when compared with other RemoteDesktop solutions. https://www.supremocontrol.com/

I have not help to offer but can confirm that F1 works fine for me (and did do "straight out of the box").

Ah! an idea - assuming you are building a 32 bit app: Are you using the Borland "Classic" (aka - very old C++ standard) compiler? menu: Project | Options | C++ Compiler - make sure the "use classic borland compiler" is set to "false" (this will then use the clang32 compiler. It's slower to build.

If you want to write portable C++ that will compile outside of VCL then you have to avoid all VCL classes (eg String). If you just want the thread implementation to be able to compile outside of VCL then avoid VCL thread classes (which do work for C++ Builder of course) and use std::thread from the C++ STL. (std::thread also works fine for RAD Studio 11 (and 12 of course)). Not sure why your two include statements should cause problems. I use exactly this in code, regularly. does #include <string> or #include <vector> also throw up compile time errors?

OK I have a work around for this issue. It assumes that users have downloaded the GoogleTest library from getit using RAD Studio (or C++ Builder) 11. Details are at this blog: https://wordpress.com/post/cigolblog.wordpress.com/716

See https://blogs.embarcadero.com/we-are-experiencing-a-hardware-outage/

I am using C++ Builder (RAD Studio 12.0) compiling to a Win64 VCL project working with PostgreSQL 13 database. RAD Studio 12.0 includes the bug fix of RSP-28292 - use of SQLTimeStampOffset fields in FireDAC. I have fields in my postgreSQL tables that are type TimeStampWithTimeZone. When viewed using PgAdmin4 they display values such as 2024-01-15 15:05:12+00 (for winter in the UK = UTC) or 2016-06-09 15:13:03+01 (for summer in the UK = BTS - one hour ahead of UTC). I use fireDAC TFDQuery and obtain datasets with these fields in. If I use // ToBeRead is the TField pointer within the dataset (typically obtained using FieldByName()) TSQLTimeStampOffset UTC_O = ToBeRead->AsSQLTimeStampOffset; Then I get a value in UTC_0 which has a time offset figure of zero and the hours compensated for. Using the above two examples this would mean UTC_0 would be equal to {2024, 01, 15, 15, 05, 12, 0, 0, 0} or {2016, 06, 09, 14, 13, 03, 0, 0, 0} // note: time offset is returned as zero and the hours value has been decremented by 1 This is not the behaviour I expected. I thought I would get the value as local time and with the time offset value set to the same value as displayed by pgAdmin4, ie for the summer case, I would expect {2016, 06, 09, 15, 13, 03, 0, 1, 0} // result in BST and time offset = 1 hour Users of my software want to see the time values displayed in local time (of course) so I have to convert this UTC value to BST for date/time values in the summer. RAD Studio 12.0 doesn't seem to implement functions UTCToLoca() or LocalToUTC() for arguments of type TSQLTimeStampOffset. It DOES implement these functions for type TSQLTimeStamp. So I am forced to first convert my TSQLTimeStampOffset to a TSQLTimeStamp value and then convert it to local time. I use this code.... TDateTime GetPgSQLDataSetFieldAsLocalTime(TField *ToBeRead) { TDateTime LocalDateTime; if (ToBeRead) { // Reading AsSQLTimeStampOffset seems to return UTC value // (ie TimeZone is Zero and hours (+days etc) have been compensated correctly) // This is not ideal ! TSQLTimeStampOffset UTC_O = ToBeRead->AsSQLTimeStampOffset; TSQLTimeStamp UTC; UTC.Year = UTC_O.Year; UTC.Month = UTC_O.Month; UTC.Day = UTC_O.Day; UTC.Hour = UTC_O.Hour; UTC.Minute = UTC_O.Minute; UTC.Second = UTC_O.Second; UTC.Fractions = UTC_O.Fractions; TSQLTimeStamp Local = UTCToLocal(UTC); LocalDateTime = SQLTimeStampToDateTime(Local); } return LocalDateTime; } This all works but it all has the feel of being a "work around". To update the field from a local time I am now using this code. void UpdatePgSQLDataSetFieldFromLocalTime(TField *ToBeUpdated, TDateTime LocalDateTime) { if (ToBeUpdated) { TSQLTimeStamp Local = DateTimeToSQLTimeStamp(LocalDateTime); TSQLTimeStamp UTC = LocalToUTC(Local); TSQLTimeStampOffset UTC_O; UTC_O.Year = UTC.Year; UTC_O.Month = UTC.Month; UTC_O.Day = UTC.Day; UTC_O.Hour = UTC.Hour; UTC_O.Minute = UTC.Minute; UTC_O.Second = UTC.Second; UTC_O.Fractions = UTC.Fractions; UTC_O.TimeZoneHour = 0; UTC_O.TimeZoneMinute = 0; ToBeUpdated->AsSQLTimeStampOffset = UTC_O; } } Again, this all works. But it all seems fairly "hard work" to code. I post the code here in case it helps anyone out. I am interested to know if anyone has a better way of working with TimeStampWithTimeZone field types and local time values.

Just realised I missed out the (trivial) definitions of AllOkA and AllOkB at the top of the code: For completeness I add: bool AllOkA = false; bool AllOkB = false;

I thought I would add some code with "what doesn't work" and how to use the above two functions to make it work. Assume you have a postgreSQL database connected and that you have a query that returns a record that contains a date/time value and that the database stores this value as a "time stamp with time zone" format (PostgreSQL users can call this timestamptz). I would expect the following code to work - but after you run it AllOkA is true (showing it works for UTC local time) but AllOkB is false (showing it falls over for BST (British Summer Time)). TFDQuery *FDQuery = SampleFDQuery; // a query which returns a record with a timestampwithoffset field FDQuery->Close(); // work with the oldest record (any one would do) FDQuery->ParamByName(SSQP_PrimaryKey)->AsLargeInt = 1; FDQuery->OpenOrExecute(); FDQuery->First(); // should only be one entry TField *Field = FDQuery->FieldByName(PG_Sensors_TimeDate); // try a winter time (January) (this is UTC - works without special function calls TDateTime WinterLocalDateTime{2020, 1, 17, 9, 8, 7, 0}; FDQuery->Edit(); Field->AsDateTime = WinterLocalDateTime; //=== FDQuery->Post(); FDQuery->Close(); FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); TDateTime Check = Field->AsDateTime; //=== FDQuery->Close(); AllOkA = (WinterLocalDateTime == Check); if (AllOkA) { FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); // try a summer time (June) (BST - one hour ahead of UTC) TDateTime SummerLocalDateTime{2020, 6, 17, 9, 8, 7, 0}; FDQuery->Edit(); Field->AsDateTime = SummerLocalDateTime; //=== FDQuery->Post(); FDQuery->Close(); FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); Check = Field->AsDateTime; //=== FDQuery->Close(); AllOkB = (SummerLocalDateTime == Check); } If I replace the lines with comments //=== with calls to the functions given in my previous posting I get code that works for both winter and BST summer times (ie both AllOkA and AllOkB are true at the end of the code). TFDQuery *FDQuery = SampleFDQuery; // a query which returns a record with a timestampwithoffset field FDQuery->Close(); // work with the oldest record (any one would do) FDQuery->ParamByName(SSQP_PrimaryKey)->AsLargeInt = 1; FDQuery->OpenOrExecute(); FDQuery->First(); // should only be one entry TField *Field = FDQuery->FieldByName(PG_Sensors_TimeDate); // try a winter time (January) (this is UTC - works without special function calls TDateTime WinterLocalDateTime{2020, 1, 17, 9, 8, 7, 0}; FDQuery->Edit(); UpdatePgSQLDataSetFieldIfNotDefaultDate(Field, WinterLocalDateTime); //=== FDQuery->Post(); FDQuery->Close(); FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); TDateTime Check = GetPgSQLDataSetFieldAsLocalTime(Field); //=== FDQuery->Close(); AllOkA = (WinterLocalDateTime == Check); if (AllOkA) { FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); // try a summer time (June) (BST - one hour ahead of UTC) TDateTime SummerLocalDateTime{2020, 6, 17, 9, 8, 7, 0}; FDQuery->Edit(); UpdatePgSQLDataSetFieldIfNotDefaultDate(Field, SummerLocalDateTime);//=== FDQuery->Post(); FDQuery->Close(); FDQuery->OpenOrExecute(); Field = FDQuery->FieldByName(PG_Sensors_TimeDate); Check = GetPgSQLDataSetFieldAsLocalTime(Field); //=== FDQuery->Close(); AllOkB = (SummerLocalDateTime == Check); } I do not have a copy of Microsoft SQLServer but I would think it very likely that the same problem exists with this too. (but am wise enough to wait for someone else to verity this !).

It is very unusual to want to create an XML file and then at some later time set the values. What purpose does an XML file with no values in serve? How you create an XML file from data values that you have is (probably) your question. The answer to this may depend on where the values are coming from. The Embarcadero XML mapper tool (available on Getit - EXCEPT AT THIS MOMENT IN TIME (JAN 2024) GETIT IS BROKEN) allows you to take <at design time> an existing *.xsd schema and create a transofrmation that can then be used in your code so that <at run time> a TClientDataset can generate an XML file from the data it contains. I am aware that I am not helping with the "using OmniXml" part of your question but I mention the above in case it helps.