Roger Cigol

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?

I think this question is becoming "how do I step (debug) into the VCL in C++ VCL Windows 64bit project. I am on Windows 10 - RAD Studio 11.2 with patch 1 I have created a simple dummy VCL C++ project. Set static linking. Set "use debug dcus". If I target Win32 I can single step into VCL (eg breakpoint on Hide() in line 22 of unit2.cpp. Clicking on the IDE step into button leads me into the VCL code where it sets the property Visible to false. All good. If I compile for Win64 when I get to the break point it breaks but this time the IDE step into button just steps over the Hide() function. Library path is strange. For windows 64 it uses the same default path: $(BDSLIB)\$(PLATFORM)\debug but this is greyed out for Win64 (indicating that it is not a valid path). My installation is on my "D:" drive. I think these macros equate to D:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win64\debug. This directory exists and looks as if it has all the files I expect. If I explicitly add this path ( D:\Program Files (x86)\Embarcadero\Studio\22.0\lib\win64\debug) to the library paths it appears not-greyed-out (ie it is valid). But no change to behaviour when I try to step into Hide(). If it needs this library path to build the exe I don't understand how it manages to build without it being there. Maybe the "greyed out" library path is valid ? Project source (no exe) as a zip file attached. C Code Hide Show 64.zip

I am not certain that I've single stepped into the VCL code before. But it doesn't seem to be working. Can anyone advise what I am missing, please? I have set project | options | Delphi compiler | compiling | use debug .dcus to true (all the options in this "debug" section are set to true or to their highest level) I have done a project "clean" I have compiled (ie full build) the Clang64 code with "debug" settings. When I run the code (under the IDE) it does stop at breakpoints ok. I wait for my code to get to the "faulty" state (ie with the form on the screen and Visible property set to false). I hit my recently added extra button and it breaks at my break point in the OnClick event handler ok. I can confirm that the "this" value matches the displayed value on my form. The event handler has the single line of code: Hide(); I now try to single step INTO this function and it just jumps over to the end of the event handler, rather than going into the VCL pascal which is what I was expecting (and wanting) it to do.

Hi Remy - it's a 64 bit app - but other than that your advice is (as always) a good idea of what to try next. Thank you. I already have another "debug aid" button who's on click handler calls Hide() - and this doesn't cause the form to go away in this fault condition (it does "hide" it (ie make it non-visible) when i click on it when it is all working and expected to be visible)). This will provide a convenient entry point for the stepping as you describe. Might be a challenge to follow the thing through but I'll give it a go.