Roger Cigol

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.

I am finding problems with RAD RAD Studio 12.0 - running C++ using Clang 64bit for a windows VCL project. If I insert a breakpoint it stops ok when the execution reaches the breakpoint. If I then try to single step sometimes it works. Most often I get a dialog appear (as per attached screen shot) but both "Wait" and "Terminate" buttons are frozen. Task manager shows RAD Studio is usage is "high" but everything is frozen. Only recovery is to shut down the entire RAD Studio using Task Manager. I get the same problems if I try to run it on a remote windows PC, deploying using PA Server. Anyone else seen this ?

I think I have found the area of my problem. If I put my breakpoint(s) in areas of code where "normal" code functions are happening then all is well. The opposite of "normal" is if I put a breakpoint in code that is interfacing with my postgreSQL (version 13 - 64 bit) database inside a database transaction then the debugger seems to hang / or do all sorts of bad things. I have my postgreSQL configured with various time outs. It makes debugging complicated database interaction (with several TFDQuery updates being used in one transaction) a bit tricky - but the IDE seems reliable if I avoid this - which is something that is workable.

Thank you Brian, I was not aware of this tool.

It also seems that the Getit package manager server is down - my "Getit" tool reports "No results found"

...and if you look in the sub directory __history you would find files *.pas.~1~ (and possibly *.pas.~2~ and *.pas.~3~ etc). These are the backup copy(s) you need. (The one with the highest number is the most recent).

Are you looking in the __history directory ?

Clipboard history was removed. The argument (probably valid) was that the Windows clipboard history does the job just as well (or better). Use left hand "Windows icon" key combined with "V" to bring up clipboard history.

It might be useful to edit the title of this post to "DUnitX passed in params are confusing" <ie add in the "X" on DUnitX> since this post refers to DUnitX (and not to DUnit). This may help people in the future who search on "DUnitX" for DunitX related postings.