Roger Cigol

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 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.

Hi Brian, A good point (and accurate). But I think I am happy that this is not the problem because the same underlying message approach is used to update the form contents and on the "visible but Visible = false" form there is a tick counter being displayed (in TrashEdit->Text) and this IS seen to be updating. Also a debug aid button on the form works - in it's OnClick event I reset the trash counter to zero and this happens when I click it. I think this all means there is no block on the main VCL message loop.