Roger Cigol

Well this is strange (and still puzzling and worrying). I was working on a different project yesterday and earlier today (a 32 bit VCL C++ clang project). And I've just gone back to this "problem" project and now it links ok. What can be going on here?

I am puzzled / worried. I've just checked out (of Git) the previous version sent to the customer as a compiled and working *.exe file and this now won't link - giving the same out of memory error. What can change that causes the linker to work with the source code at some point and then later not work ? where should I be looking to solve this problem ?

Hi Hans, Sorry about wrong word in my original question: I have edited this to read "diagnostic". Sometimes I have seen TwincCompile catch these messages, but sometimes not. For testing, once you have all the files compiled (takes 10 mins with twine compile) I turn Twine Compile off, Set verbosity to diagnostic and do a "make" again. This checks all object code is still ok (it is) and then jumps straight to doing the linking. The output I get is as follows (edited to save space and maintain customer confidentiality): Done building target "_CheckLinkDependencies" in project "MYPROJECTNAME.cbproj". Target "_PerformLink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets": Task "CallTarget" Target "_PerformBCCILink" in file "d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets": Using "ILINK32" task from assembly "d:\program files (x86)\embarcadero\studio\22.0\bin\Borland.Build.Tasks.Cpp.dll". Task "ILINK32" d:\program files (x86)\embarcadero\studio\22.0\bin\ilink64.exe -G8 -L.\Win64\Release;"BIG LONG LIST OF OBJECT CODE FILES HERE", .\Win64\Release\MYPROJECTNAME_resources.res .\Win64\Release\MYPROJECTNAME.res Turbo Incremental Link64 6.97 Copyright (c) 1997-2022 Embarcadero Technologies, Inc. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2. Done executing task "ILINK32" -- FAILED. Done building target "_PerformBCCILink" in project "MYPROJECTNAME.cbproj" -- FAILED. Done executing task "CallTarget" -- FAILED. Done building target "_PerformLink" in project "MYPROJECTNAME.cbproj" -- FAILED. Done building project "MYPROJECTNAME.cbproj" -- FAILED. Build FAILED. d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): warning : Warning: Out of memory d:\program files (x86)\embarcadero\studio\22.0\Bin\CodeGear.Cpp.Targets(3984,5): error MSB6006: "ilink32" exited with code 2. 1 Warning(s) 1 Error(s) As you see: I do NOT get any indication of which heap size has caused the memory overflow. If I repeat the make with Vertosity set to "Normal" I do get slightly less information in the output - so the setting is having some effect. But no sign of any heap information.....

I find the same with the clang code completion - it sometimes works and sometimes doesn't. I know Embarcadero are aware of this and are trying to make it better. However I think the new approach that is coming (as per David Milington's recent blog) promises to get this properly sorted. It's an essential feature in the world of modern C++ IDEs. If you haven't read David's blog - here's the link: David's c++ the future blog

My experience is that for legacy projects, unless you have a really good reason to change (ie a major new requirement where you'd like to use modern C++ code constructs) then stick with Classic. I still use Classic for significant (to my customers) projects. It does build much faster than the clang compiler. I most definitely wouldn't dream of using clang without the benefit of TwineCompile because the build times would become unmanagable. I wonder why you can't get TwineCompile to work with your classic compiler? I use TwineCompile for all projects and wouldn't want to be without it. I've never had a problem with a classic compiled project working/not working with TwineCompile. {too many negatives: I mean: Classic compiler projects always work with TwineCompile for me).

... try renaming the file back to .jpg and then try to open it with a photo viewer app and see !

Documentation is useful for questions like this: https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.UnicodeString_Methods

Hmm - last bit of my previous post doesn't seem to have been displayed / submitted correctly. I also included a line of code: char ch = myString[1]; // rem: this is an example of use and does not include a check for an empty string

Your have defined AnsiString myString But then not used it..... myString = AnsiString(EditCharacterEntry -> Text);

Remy is (of course) correct. My example was to show you one possible solution. You would be wise to check for the String being empty before doing the conversion. String type has a function IsEmpty() to do just that.

Working with Alexandria 11.2 - I am using a C++ builder Win 32 "classic" VCL project. If I use project options and specify a "custom" windows manifest file it allows me to specify a full path to a manifest file that I can manually create (and the IDE encourages me to use an extension *.manifest). If I enter a full path to a custom manifest file but (owing to my mistake) this manifest file does not exist the project still builds my *.exe target file without reporting an error. But (obivously) the resulting *.exe file cannot include the custom manifest information that I intended. I would have expected a linker error "can't find manifest file xxxxMyCustomFileNameHerexxx.manifest" rather than letting my mistake pass through unnoticed. Can anyone else confirm that they get the same behaviour (also with a Delphi VCL 32 bit project ?)....

The EditCharacterEntry->Text is a Unicode string (remember it would be possible for someone to enter several characters (including characters that can't be represented as C++ char type). So the first thing you need to do is to convert this to an 8 bit char string. Any easy way to do this is to construct and AnsiString from the Unicode String. So you use AnsiString(EditCharacterEntry->Text). This will lose (ie corrupt) characters that are Unicode and can't be represented in Ansi. Next you need to get the first character of the AnsiString. In a VCL framework application the first character has an index of 1. So you use char ch = AnsiString(EditCharacterEntry->Text)[1];

Hi Remy, Thanks for your valuable input. I am aware I haven't offered a "minimum reproduceable error" set of code for my posting. This is my next step - just two threads - one passing a number to the other using my interface class. I will do this later this week and post it up here (assuming I get the same error). The code I do have which is showing the problem is a googletest framework unit test which seems to run ok on gnu/linux but not on Embarcadero - but I agree this could still be a bug in my code.....

I have a working class to interface to a COM interface (created by a 3rd party). My working class is a wrapper around the type library functions I generated using C++ Builder. This code works 100% when compiled under C++ Builder 10.4. I have just used the same class in a new application running on the same machine as the working system but this time compiled using 11.2 patch 1. This doesn't work. The problem seems to be in passing pointers to BSTR. I use WideString.c_bstr() to get the pointer to the BSTR to pass to the COM interface. QUESTION: can anyone confirm that this approach works ok using 11.2 ? (or should I be looking into this at a lower level with a view to creating an Embarcadero RSP bug report?)

I've created an RSP. https://quality.embarcadero.com/browse/RSP-41374

You can use TEdit or TLabelledEdit for basic user input, along with a myriad of other visual components to get input from a user. Similarly for output. The basic "Message Box" is not a C++ Builder feature but part of the operating system (assumed to be Windows since you don't say otherwise). C++ builder VCL does provide a convenient "wrapper" for the operating system message box: https://docwiki.embarcadero.com/Libraries/Alexandria/en/Vcl.Forms.TApplication.MessageBox

What C++ compiler are you using? Can you post the contents of form file (*.dfm) that corresponds to the two components TGridLayout and HorzScrollBox1. (or create a complete form that is a minimum not-working example) and paste the entire *.dfm file).

This is somewhat pessimistic. For an optimistic look at the future go to this recent posting: https://blogs.embarcadero.com/whats-coming-for-cbuilder-an-amazing-preview/

I am a professional developer (for industrial control systems) and use Embarcadero C++ (mostly using the VCL framework) extensively. Yes, Microsoft dominate the Windows C++ arena, but Embarcadero C++ with VCL is a great tool. Post questions in the C++ sub forum here on Praxis and (provided you clearly explain your challenge) there is a good chance you will get an answer.

I've seen this happen if you have two copies of a c++ *.h header file open in the IDE (in two separate windows). You edit one copy and then later save the other uneditied copy and overwrite the changes. Not sure if it's possible to have two copies of the same pascal + *.dfm unit open or not. Just something to check though.... I've also had a multiple projects issue where different projects refer to the same file. If you at some point move the directory in which the file is in and then only update some of the projects you accidentally introduce two copies of what should be only one file. This has happened to me a couple of times and caused great confusion ! Just another thing to check - make sure full path of the file is the same in all the projects.....

Anyone who gets to this post should be aware that in March 2023, with Alexandria 11.3, there was a new version of XML Mapper in Getit. See also this post:

Hi Lars, There is a numeric entry box for this limit on the XSD tab

I realised that - but that seems to me to be a good reason to use it. Or is the problem that it ONLY uses UDP so there is no guarantee that all data gets through all the time ?

I have been following this forum and am interested that no-one has mentioned the Delphi "App Tethering" components which I thought were specifically designed to help make this task straightforward. Am I incorrect or does AppTethering not work well? (I hope I am not going to distract the forum question from the main question by asking this here)

A definite improvement - thanks Remy.