Roger Cigol

Good to mention that you are using Oracle Virtual Box. I see no reason for this to prevent you from installing community edition (I can confirm that the full version of RAD Studio does install and run ok in Oracle Virtual Box). Can you reach the internet from within your virtual box (ie open web sites with a browser) ?

I definitely agree with this (even though I am not quite sure who I am agreeing with !)

I agree with @Attila Kovacs < not! >

I agree with @Attila Kovacs Irony and Sarcasm are rarely helpful in a forum such as this. Good in pubs when discussing over a beer or two perhaps. If I feel a need for a bit of sarcasm I try to remember to add a hint such as < not! > after the sentence. By the way I am in the category of using EBT for "useful" rather than "beautiful" software.

I have now confirmed that with RAD Studio 10.4.2 I can get my COM interface to work correctly when compiled with either "Classic" or Clang32 compiler. And to repeat: neither compiler produces working results when compiled with 11.2.

Yes. I agree exactly with your diagnosis. It looks to me as if something has changed with the TAutoArgs or OleFunciton() handling of the BSTR type with the "jump" from 10.4.2 to 11.2.

Thanks to all for input. SINCERE APOLOGIES : I accidentally created a "red herring" when I quickly replaced the actual test label path (which is long with lots of customer sensitive directory names) with "C:\FullPathToLabelFile.lab" and forgot to use the double \\. The actual label file path is correctly formated (ie includes \\). @Lars Fosdal The 10.4.2 (working code) uses the classic compiler. The 11.2 (patch 1) code does not work with either the classic compiler of the clang32. I am running this on a remote PC (at the customer's premises) and need to interrupt their production to use the PC so testing is a bit tricky (and it also feels like I am hanging out dirty washing for everyone to see, each time I do a test and can't get it to work). I didn't think to try compiling under 10.4.2 using the clang32 compiler. I will try to do this next time I "log in". [ I use Supremo for remote access to the PC ]. @Remy Lebeau By using the IDE debugger I have confirmed that the BSTR inside the call to Open() does indeed contain the correct label path. I accept all your other observations as good programming hints (although constructing a String (aka UnicodeString) by passing a constant array of 8 bit chars can't be a bad thing - as long as the 8 bit chars are all simple ASCII chars). But they are not the cause of my interesting problem. I don't feel a need to check for the [ exceedingly unlikely ] failure of the internal call to the Win32 SysAllocStringLen() function because if this does fail the resulting error of "Can't open the label file" is going to be good enough. The key thing is that when the BSTR passed to Open() is a valid path to the file then it needs to work (as it does under 10.4.2).

We have been chasing this problem. The COM interface we are talking to is for the CodeSoft printer software (supplied by Teklynx). We have this bit of code String LabelName = "C:\FullPathToLabelFile.lab"; ResetFloatingPoint(); // our function to reset FPU flags CodeSoftDocument = CodeSoft->Documents->Open(WideString(LabelName).c_bstr(), 0); if (!CodeSoftDocument) { MostRecentError = LPE_CantOpenLabelFile; } else { MostRecentError = LPE_Ok; } If we compile this under 10.4.2 we get MostRecentError = LPE_Ok. (and the label prints) If we compile this under 11.2 we get MostRecentError = LPE_CantOpenLabelFile (and no label). If trace this down into the wrapper for the type library we find the definition of the Open() function as follows Labelmanager2_tlb::IDocument* __fastcall Open(BSTR strDocName/*[in]*/, VARIANT_BOOL ReadOnly/*[in,def,opt]*/) { TDispID dispid(/ Open / DISPID(7)); TAutoArgs<2> _args; _args[1] = strDocName /*[VT_BSTR:0]*/; _args[2] = ReadOnly /*[VT_BOOL:0]*/; OleFunction(_dispid, _args); return (Labelmanager2_tlb::IDocument* /*[C1]*/)(LPDISPATCH) /*[VT_DISPATCH:1]*/_args.GetRetVariant(); } CodeSoft has a debug mode - and this shows us that under 11.2 the label file name is being interpreted as a NULL BSTR (hence it can't open the label file).

Go for it. If you pass you feel good and you have something to put on your CV. If you fail it is probably more useful as a) it makes you less likely to be arrogant. and b) it gives you areas that you can focus on to learn more and hence stimulate your mind and perhaps become a slightly better more experienced programmer....

Still looking...... (and happy Christmas to all Embarcadero users out there)

I just use an TFDQuery with the SQL statement set to SQL CreateTable statement (created either at design time or at run time as suits your needs) and then call Execute() method of the TFDQuery

Hi Remy, Well that would explain why I can't find it ! But it doesn't explain why I've suddenly had to change a working using MainDLL() project to having to use DllEntryPoint() in order to get it to work. My own notes suggest that the last time I rebuilt this project was 11.1.5 - so I suspect the change has happened just with 11.2 Any way thanks for your help. As I have solved the problem it's probably not worth further chasing !

Certainly not my intention to do that. Of course there are other source control solutions too. My intention was to point out that trying to do version control / source control manually is rarely (if ever) a sensible use of someone's time these days. Sorry if I sent out wrong "messages" here....

Solving all this versioning issues is exactly what git was invented for and exactly what it does so well and so easily (espeically if you install tortoise git into windows). It's all out there for free and takes a day or two (max) to get the hang of.

You can only do this if you have RAD studio - ie the version with both Delphi and C++. It may be possible to build a separate library with a separate build system (eg GCC or MSC++) and then call this from Delphi - but I would expect lots of effort required to get the naming and parameter passing all working ok. I would be wary about going down this route......

You can purchase RAD Studio - which gives you both Delphi and C++ Builder. Be careful with the statement " most c++ libraries do not compile with c++ builder" - Some do, some don't - "most" is an unhelpful adjective here. If the ones you want to use compile that's what you want..... C++ multi-platform is weaker than Delphi - not having Android is a real shame. Going back to your original question "Do you think Embarcadero would let me switch my license from Delphi to C++ builder?" - This is probably a very unusual request (and I am sure they would try to sell you an "upgrade to RAD Studio (ie add C++ builder)" rather than a straight switch. What would happen to all your current delphi projects?

I am grateful to Glenn Dufke for pointing out the following video - long but worthwhile ! I add my youtube comment here as a way of starting a discussion: A great presentation (especially liked a guru like you failing to get the gcc to run!). Very ambitious vision - but it's good to "aim high". Could a compromise be to have a Cpp release that prohibits (not just deprecates!) the "unsafe" historic features (eg union, pointer arrithmetic, new/delete etc etc), forces use of bounds checking and std::span but without introducing the new syntax? Might not be so elegant and would not reduce your "teaching load" so much but might get through the inevitably cumbersome standards committee? Or do you realistically see Cpp2 as a fork away from the standards committee (sorry to be so heretic!)?

I live in that world ! But tell me what GUI you would use with Rust that comes close to VCL or FMX ?

It is true that C++ has evolved greatly. Actually in almost all cases it is backward compatible (and the few cases it isn't are often particularly flakey coding edge cases). There are some serious brains greatly improving the concepts behind writing sound code working on C++. It's fascinating (but time consuming) learning (and understanding) about the thinking behind some of the additions. The thinking behind sticking to C++ is a) access to a lot of third party libraries. b) not tied to one particular vendor's compiler (there are three compilers still very active out there: MSC++, GCC and Clang). c) There are many more C++ programmers out there than delphi. Of course b) is a great self deception: the extensive use of the (still beautiful after all these years) VCL framework does tie me to Embarcadero - although much of my more recent (in the last 10 yrs) code has good separation between the GUI and the "nitty gritty business" code the GUI is still an area that takes a lot of time to get right (ie how the customer likes it) so it would be very painful to swap to one of the competitors <but not impossible>. Of course c) is a great self deception as all the good C++ programmers have good jobs ! and actually a) is true but as yet I don't use a great many 3rd party libraries. ...... so perhaps you are right !

I don't see an Embarcadero Rust VCL/FMX appearing any time soon.....

A very valuable posting has appeared on Stack Overflow regarding using Google Tests with Embarcadero C++ clang compilers. Thank you to T. Herzke for sharing this. More useful info on C++ google tests unit test

.... And am still looking ....

I have to point out that the upgrade to 11.2, installing over 11.1.5 went without any issue for me (installed from ISO image). It's true that I did have an issue discussed (and resolved) in the link below but the installation went without any issue.

I have a 350+ file project that built just fine with 11.0, 11.1 and 11.1.5. Its a windows 64 bit VCL project. It has a set of unit tests (googletest) that builds under 11.2 ok. It has a small "test utlititly" that is also Win64 VCL and that too builds ok under 11.2 But when I try to compile the main project all the files compile ok but the linker fails. I get the following output which I am having trouble interpreting. Any ideas about what might cause this ? [MSBuild Error] CodeGear.Cpp.Targets(3984, 5): MSB4018 The "ILINK32" task failed unexpectedly. System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) at Borland.Build.Tasks.Common.Metadata.Option.ParseInt64(String value) at Borland.Build.Tasks.Common.Metadata.Option.IsDefaultValue(BaseTask task) at Borland.Build.Tasks.Common.Metadata.Option.AppendCommandLineSwitch(BaseTask task, CommandLineBuilder b) at Borland.Build.Tasks.Common.BaseTask.AddOptionString(CommandLineBuilder b) at Borland.Build.Tasks.Cpp.ILINK32.AddOptionString(CommandLineBuilder b) at Borland.Build.Tasks.Common.BaseTask.GetCommandLine() at Borland.Build.Tasks.Cpp.ILINK32.GetCommandLine() at Borland.Build.Tasks.Common.BaseTask.GenerateCommandLineCommands() at Microsoft.Build.Utilities.ToolTask.Execute() at Borland.Build.Tasks.Common.BaseTask.Execute() at Borland.Build.Tasks.Cpp.ILINK32.Execute() at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult)

An update: it seems the real problem with my linker options was that one of the heap size settings had been entered (by me) with a leading space. It seems the MSBuild process doesn't like this. By deleting and then re-entering the numbers I removed the leading space and hence it all "sprung into life".