Roger Cigol

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.

You could tell us a bit about yourself too. Experience, interests, What version of RAD Studio you have etc etc. Do you have any C++ expertise ?

This looks like standard compiler memory alignment to me and is entirely expected. I am pretty sure that the compiler writers would take (gentle) issue with your "really no good reason" statement. I am not sure why it makes static analysis difficult - memory alignment is a common feature of many (most?) compilers. What static analysis tool are you using and where do you find the problem?

This is arguably one of the other significant benefits of designing code with Unit Testing in mind. It encourages you to write loosely coupled (or better entirely self standing) modules.... If you are dealing with legacy code this might be the case - but that doesn't mean that it is not worth effort. If you intend to keep the code live and supported for the future it almost certainly IS worth refactoring.

Most of the basic editing functions and keyboard short cuts of the text editor apply equally to Delphi or C++. But IDE menu Tools | Options and then scroll down to User Interface | Editor | Key mappings and the list of "out of the box" configurations does NOT include VIM.

I use it. Maybe I am a "nobody" ?

Actually, having said this before the webinar, I feel I should correct myself: the Visual Assist (including basic refactoring) looks like a HUGE step forward.

And if you ARE using C++ builder version 12.0 does not quite deliver as much as you'd think. The much anticipated new tool chain is only present if a very limited "preview" form.

Hi John, There's a webinar to tell you exactly this. Tomorrow (9th Nov) and also a blog summary: Marco's blog on Athens 12 If you scroll to the end of this blog there is a link to sign up for the webinar. I will be listening/watching in....

..... and I am still hoping that with the new C++ approach that will eventually come there will after that eventually be Android 64 bit C++ support.

I have an Alexandria 11.2 patch 1 VCL 64 bit windows application. I get the same problem running as an independant exe file or running under the RAD Studio IDE. I have a tick driven check function that has made the window invisible to the user by calling Hide(), on a previous tick. Then it checks for the state of a separate thread (via a lock to ensure concurrent access is ok). When the other thread indicates that it is ready to display the form it sets a flag and I then call Show() to display the form to the user. This works most of the time. But, rarely, I get to the checking state but the user can still see the form. I have added a check in the code to change the form colour if Visible == true (as a debug aid) and it DOES NOT change colour - so I know Visible is false. Here's my code where this occurs: case TSGS_WaitingForDisplayDecision: Status = "Waiting for display decision"; // elsewhere this is displayed on the form if (TestControl[TestControlID]) { TTestControlGUIInterface Info; TestControl[TestControlID]->TestControlGUIInterfaceData.Read_TS(Info); if (Info.GUIShouldBeVisible) { State = TSGS_DisplayMainTestForm; // this next state calls Show() to display the form } else if (Visible) { Color = clTeal; // when the fault occurs the form can be seen but it stays at the default colour } } break; a breakpoint at the line "Color = clTeal" is never hit - even though I can see the form on the screen <when the fault is present>. A breakpoint elsewhere in the code shown above is hit so I know I am passing through this state. Has anyone else ever seen anything similar?

I am interested in the library information passed to the linker. With my simple hide show project (source code zip already included above) if I compile for Win64 for debugging and have no entry in the Project | Options | C++ Shared Options | Library path for any of the available levels of the tree (ie nothing in All configuration all platforms, nothing in All configurations - Windows 64, nothing in Debug configuration, nothing Debug configuration - Windows 64 and nothing in Release configuration and nothing in release configuration Win 64) if I then look at the text in the Console Output tab following the TwineCompile full build I can see the paths passed to the ILinker as parameters of the -L switch. These are as follows: -L.\Win64\Debug; "d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release"; "d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release\psdk"; C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64; C:\Users\Public\Documents\Embarcadero\Studio\22.0\DCP\Win64\Debug;C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64 I don't think the second and third in this list should be "release" - I think they should be "debug". But how to fix this? where do these come from? If I open up the project file with a text editor and search for "release" there is no entry that is related to library file specification. so I don't think it is a problem with the project file.

Hi Harry, thanks for this: All help appreciated. In my case the form is NOT autocreated (I've removed it from the list in project | options). By displaying the value of "this" in my debug TEdit box and hitting a breakpoint I can confirm that I am on the correct instance of the form. Also the TEdit box clearly indicates that the form visible property is false - yet I am reading the TEdit box contents as it IS visible on the screen. This should never happen.

Hi Harry, thanks for this: All help appreciated. In my case the form is NOT autocreated (I've removed it from the list in project | options). By displaying the value of "this" in my debug TEdit box and hitting a breakpoint I can confirm that I am on the correct instance of the form. Also the TEdit box clearly indicates that the form visible property is false - yet I am reading the TEdit box contents as it IS visible on the screen. This should never happen.

Going back to my original problem I am suspicious of the library issue. One reason for this is when I explicitly add the library path D:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win64\debug to my project the problem still happens but seems to be much rarer. Over the next few days (weeks?) I am going to try removing this path and running again to confirm that this statement is true (sometimes it takes an hour or more for the problem to appear). I will also try running it in "release" mode. If there is a release library being chosen for some reason that doesn't match a debug library (is this possible?) then a release mode build might be expected to run perfectly. This will take some time...... Remy is absolutely correct here

STOP PRESS - I now know (from info direct from Embarcadero) that it is not possible to single step into VCL on a Win64 C++ project with RAD Studio 11.2. Delphi and Clang64 use different debuggers in this case.

If I compile my simple sample project (C Code Hide Show 64) with static linking for either Win32 or Win64 with the Project | options | C++ shared options | Library path complete empty it still builds, links and runs ok. Somehow the linker must know about the library file path..... How can I tell which path it is using ? (maybe my original problem is due to the wrong libraries being linked in?). Answer by looking at the TwineCompile console output. The Linker part of this is as follows Linking... Target _PerformLink: Target _PerformBCCILink: d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L.\Win64\Debug;"d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release";"d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release\psdk";C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64;C:\Users\Public\Documents\Embarcadero\Studio\22.0\DCP\Win64\Debug;C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64 -j.\Win64\Debug;"d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release";"d:\program files (x86)\embarcadero\studio\22.0\lib\win64\release\psdk";C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64;C:\Users\Public\Documents\Embarcadero\Studio\22.0\DCP\Win64\Debug;C:\Users\Public\Documents\Embarcadero\Studio\22.0\Dcp\Win64 -l.\Win64\Debug -v -Gn -aa -Tpe c0w64w memmgr.a sysinit.o .\Win64\Debug\Project1.o .\Win64\Debug\Unit1.o .\Win64\Debug\Unit2.o , .\Win64\Debug\Project1.exe , .\Win64\Debug\Project1.map , rtl.a vcl.a import64.a cp64mt.a , , .\Win64\Debug\Project1.res So I can see that, even though the library path is empty, the library files paths are being passed to the linker. But why is the first path in the -L switch a "release" path ? Is this why the single stepping into Hide() is not working?