alank2

I am using TNetHTTPClient and have set its timeouts (ConnectionTimeout, ResponseTimeout, and SendTimeout) to 6000 each for 6 seconds. I have a virtual machine that has an odd thing going on - if I start it (or restart it), the first time I launch the application that uses TNetHTTPClient, it will take a long time (231 seconds), but it will eventually return what is expected (no errors, no exceptions thrown). If I close the application and launch it again (without restarting the VM), it works as it should <400ms. I do have a feeling that the VM itself, for some reason, is causing this delay, but why doesn't TNetHTTPClient timeout properly? I found this: https://stackoverflow.com/questions/56416108/connection-timeout-with-tnethttpclient-and-delphi-10-3 Suggesting there is no resolve timeout, but I created a ping shortcut on the desktop to the URL I am connecting to with TNetHTTPClient and double clicked it as soon as the system was restarted. It resolved immediately and this made no difference to the 231 seconds one the program starts up for the first time.

This is C++ Builder, but it is using System.Net.Mime.pas which contains TMultipartFormData. Building with 11.3 works fine no errors, but building with 12.3 will cause a crash when I try to delete a pointer to TMultipartFormData. I added System.Net.Mime.pas and stepped into it and it calls: If I step over "FStream.Free" it crashes. If I step into it: If I step over Destroy it crashes. If I step into it, it goes into assembly: I can see a lot of differences between the the 22.0 and 23.0 versions of System.Net.Mime.pas. Any ideas on how to I can resolve this with 12.3?

>But yeah, that makes total sense now, C++'s overload resolution would indeed prefer to implicitly convert a string literal into a bool rather than a user-defined >object (ie UnicodeString), and that would explain your crash if AOwnsStream were implicitly being set to 'true' and then you try to free both streams yourself. I have seen this type of thing before and wondered if that is what could be going on. I've run into it before changing a char* pointer to an integer expecting deprecated code to catch it as an error/warning reminding me to correct it, but it doesn't. void myfunc(bool A) { if (A) Form1->Caption="true"; else Form1->Caption="false"; } myfunc("Hello"); //calls as true myfunc(NULL); //calls as false In this case, it is evaluating the string pointer as non-zero and becoming true. but NULL is false. >So, do the conversion explicitly and then you will hopefully see the warning: Yes - indeed so! :

I had a program using TIdSMTP that works fine on my Windows 10 box using ssleay32.dll/libeay32.dll version 1.0.1.13, but when I try to execute it on a Windows 11 box, it fails if I have TLS enabled. If I disable TLS, it will work with the SMTP service I am using (mailgun) and send the email. I found this page: https://docwiki.embarcadero.com/RADStudio/Rio/en/OpenSSL#32-bit_and_64-bit_Windows Which let me to downloading openssl-1.0.2r-i386-win32.zip which had the ssleay32.dll/libeay32.dll version 1.0.2.17 versions which now will work with TLS enabled - so these newer versions do solve this problem, but it says the zip is 5 years old at github. Is TIdSMTP set up to use openssl 1 ? I saw there was a version 3 on there with different DLL names. I rebiult my project (was in 10.3.3) in 12.3, but that made no difference.

I started a brand new windows vcl project, switched to 32 bit, set the classic compiler and added these lines of code to see if I would get a warning: TMultipartFormData *mfd; TMemoryStream *send; send=new TMemoryStream(); mfd=new TMultipartFormData(true); mfd->AddStream("name", send, "value"); No warning. What annoys me here is that if I had had the warning it would have tipped me off to the problem much sooner.

3 questions: #1 - If I open a project and build it, I get 7 of this warning: [bcc32 Warning] processthreadsapi.h(1165): W8026 Functions with exception specifications are not expanded inline If I build it again, they disappear. If I close the project (not the IDE), reopen it, build again, I get the 7 warnings back for the first time, but again, not subsequent times. #2 - Another oddity, the build window shows 50 warnings. It is really the 7 warnings apparently counting at 7 each for a total of 49 plus the 1 other warning that is always present. Why not just 8 warnings? #3 - The last warning (which doesn't go away no matter how many times I build is): [bcc32 Warning] System.Net.URLClient.hpp(772): W8058 Cannot create pre-compiled header: code in header Is this something Embarcadero needs to fix in System.Net.URLClient.hpp?

>What does line 1165 of processthreadsapi.h look like? I don't see ANY exception specifications in my copy of processthreadsapi.h, but I'm using 12.2 and not 12.3. Highlighted here: >On the closing '};' of the class? Exactly. >I don't see anything that would be considered "code in header" to trip up a precompiled header, unless the compiler is complaining about the static const members. Could it be these? static _DELPHI_CONST System::Word DefaultConnectionTimeout = System::Word(0xea60); static _DELPHI_CONST System::Word DefaultSendTimeout = System::Word(0xea60); static _DELPHI_CONST System::Word DefaultResponseTimeout = System::Word(0xea60);

>I don't know why Embarcadero insists on putting the _DEPRECATED_ATTRIBUTE1 macro in between a function's name and its arguments. That just annoys me. All >examples of [[deprecated]] and __attribute__(deprecated) that I have seen use it either in front or in back of the function declaration, not in the middle. Even the >DocWiki documents it as belonging at the end of a declaration: https://docwiki.embarcadero.com/RADStudio/en/Deprecated I agree. >That is because the _DEPRECATED_ATTRIBUTE1 (and __DEPRECATED_ATTRIBUTE3) macro ignores the message text when you are compiling with the classic compiler (at least in 12.2 - I don't have 12.3 installed yet to check this): At least that is explained! >This behavior is clearly wrong/outdated for the classic compiler, given that you demonstrated [[deprecated("message")]] is able to display message text just >fine, and that behavior is even documented on the DocWiki: https://docwiki.embarcadero.com/RADStudio/en/Deprecated >I have reported the issue: RSS-3285: _DEPRECATED_ATTRIBUTE1 and _DEPRECATED_ATTRIBUTE3 ignore message text for classic compiler Thank you! >Given the above macro declarations, the only possibility I can think of is that your real project is not actually compiling with the classic compiler (which you can verify by looking at the build output messages). I turn on all warnings except 8057 parameter is never used - bcc32 is the classic compiler, right? bcc32 command line for "webapi.cpp" c:\program files (x86)\embarcadero\studio\23.0\bin\bcc32.exe -DNDEBUG;QDX_MODE=1;;FRAMEWORK_VCL -n.\Win32\Release -I"c:\program files (x86)\embarcadero\studio\23.0\include\windows\vcl";"c:\program files (x86)\embarcadero\studio\23.0\source\rtl\net";"c:\program files (x86)\embarcadero\studio\23.0\include";"c:\program files (x86)\embarcadero\studio\23.0\include\dinkumware";"c:\program files (x86)\embarcadero\studio\23.0\include\windows\crtl";"c:\program files (x86)\embarcadero\studio\23.0\include\windows\sdk";"c:\program files (x86)\embarcadero\studio\23.0\include\windows\rtl";"c:\program files (x86)\embarcadero\studio\23.0\include\windows\vcl";"c:\program files (x86)\embarcadero\studio\23.0\include\windows\fmx";C:\Users\Public\Documents\Embarcadero\Studio\23.0\hpp\Win32;"C:\Program Files (x86)\Devart\SDAC for RAD Studio 12\Include\Win32";C:\Users\Public\Documents\Embarcadero\Studio\23.0\hpp\Win32 -Q -c -tM -tW -C8 -o.\Win32\Release\webapi.obj -wamb -wamp -wasm -wbbf -wcln -wdef -winl -wnak -wnod -w-par -wpin -wsig -wstu -wstv -wucp -wuse -wprc -wstl -wexc -wimp -wntn -wpad -wiac -wbcx -wpun -O2 -v- -vi -H=.\Win32\Release\s4ebet.pch -H webapi.cpp

>In <System.Net.Mime .hpp>, is there a 'deprecated' attribute on the declaration of AddStream()? Yes: void __fastcall AddStream _DEPRECATED_ATTRIBUTE1("Use AddStream with AOwnsStream parameter") (const System::UnicodeString AField, System::Classes::TStream* AStream, const System::UnicodeString AFileName = System::UnicodeString(), const System::UnicodeString AContentType = System::UnicodeString(), System::Classes::TStrings* AHeaders = (System::Classes::TStrings*)(0x0))/* overload */; I am using the classic compiler: I found this: https://docwiki.embarcadero.com/RADStudio/Sydney/en/DEPRECATED_ATTRIBUTE0_and_DEPRECATED_ATTRIBUTE1 If I create a test function and called it: void textzzz() [[deprecated("use myFunc(int,double) instead")]] //_DEPRECATED_ATTRIBUTE1("use myFunc(int,double) instead") { ; } With this I get a warning: (But the remarked form above doesn't show the "use myFunc(int, double) instead" for some reason.) The big issue is why my call to the deprecated form of AddStream did not give a warning.

I downloaded the RAD Studio, Delphi, C++Builder 12.3 Inline ISO to install it, but when I press F1 for help I get: The installer only has two files in the ISO and when I launch the executable it wants to uninstall RAD Studio before installing it again so that doesn't seem like the help. Can the help setup be downloaded somewhere?

I found it under manage features - thanks.

>Precompiled header being compiled only 1 time? I've never had a build produce different messages before even with precompiled headers. >What does line 772 actually look like? It is the last line of this: class PASCALIMPLEMENTATION TURLClient : public System::TObject { typedef System::TObject inherited; public: static _DELPHI_CONST System::Word DefaultConnectionTimeout = System::Word(0xea60); static _DELPHI_CONST System::Word DefaultSendTimeout = System::Word(0xea60); static _DELPHI_CONST System::Word DefaultResponseTimeout = System::Word(0xea60); System::Generics::Collections::TObjectDictionary__2<System::UnicodeString,TURLClient*>* FInstances; TCredentialsStorage::TCredentialAuthCallback FAuthCallback; TCredentialsStorage::TCredentialAuthEvent FAuthEvent; TCredentialsStorage* FInternalCredentialsStorage; TProxySettings FProxySettings; TCredentialsStorage* FCredentialsStorage; int FConnectionTimeout; int FSendTimeout; int FResponseTimeout; TURLClient* __fastcall GetInternalInstance(const System::UnicodeString AScheme); System::UnicodeString __fastcall GetUserAgent(); void __fastcall SetUserAgent(const System::UnicodeString Value); protected: TURLHeaders* FCustomHeaders; void __fastcall SetConnectionTimeout(const int Value); void __fastcall SetSendTimeout(const int Value); void __fastcall SetResponseTimeout(const int Value); System::UnicodeString __fastcall GetCustomHeaderValue(const System::UnicodeString Name); void __fastcall SetCustomHeaderValue(const System::UnicodeString Name, const System::UnicodeString Value); virtual System::DynamicArray<System::UnicodeString> __fastcall SupportedSchemes(); virtual _di_IURLResponse __fastcall DoExecute(const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream, System::Classes::TStream* const AContentStream, const TNetHeaders AHeaders); virtual System::Types::_di_IAsyncResult __fastcall DoExecuteAsync(const System::Classes::_di_TAsyncCallback AsyncCallback, const System::Classes::TAsyncCallbackEvent AsyncCallbackEvent, const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream, System::Classes::TStream* const AContentStream, const TNetHeaders AHeaders, bool AOwnsSourceStream = false); virtual System::Types::_di_IAsyncResult __fastcall DoGetResponseInstance(System::TObject* const AContext, const System::Sysutils::_di_TProc AProc, const System::Classes::_di_TAsyncCallback AsyncCallback, const System::Classes::TAsyncCallbackEvent AsyncCallbackEvent, const _di_IURLRequest ARequest, System::Classes::TStream* const AContentStream); virtual _di_IURLRequest __fastcall DoGetRequestInstance(const System::UnicodeString ARequestMethod, const TURI &AURI); virtual void __fastcall DoAuthCallback(TAuthTargetType AnAuthTarget, const System::UnicodeString ARealm, const System::UnicodeString AURL, System::UnicodeString &AUserName, System::UnicodeString &APassword, bool &AbortAuth, TAuthPersistenceType &Persistence); __classmethod virtual TURLClient* __fastcall CreateInstance(); static TURLClient* __fastcall GetInstance(const System::UnicodeString AScheme); virtual void __fastcall SetCredentialsStorage(TCredentialsStorage* const Value); virtual System::DynamicArray<TCredentialsStorage::TCredential> __fastcall GetCredentials(TAuthTargetType AuthTarget, const System::UnicodeString ARealm, const System::UnicodeString URL); virtual void __fastcall SetProxySettings(const TProxySettings &Value); public: __fastcall TURLClient(); __fastcall virtual ~TURLClient(); _di_IURLRequest __fastcall GetRequest(const System::UnicodeString ARequestMethod, const TURI &AURI)/* overload */; _di_IURLRequest __fastcall GetRequest(const System::UnicodeString ARequestMethod, const System::UnicodeString AURI)/* overload */; _di_IURLResponse __fastcall Execute(const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; _di_IURLResponse __fastcall Execute(const System::UnicodeString ARequestMethod, const System::UnicodeString AURIStr, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; virtual _di_IURLResponse __fastcall Execute(const _di_IURLRequest ARequest, System::Classes::TStream* const AContentStream, const TNetHeaders AHeaders)/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::Classes::TAsyncCallbackEvent AsyncCallbackEvent, const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::Classes::_di_TAsyncCallback AsyncCallback, const System::UnicodeString ARequestMethod, const TURI &AURI, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::UnicodeString ARequestMethod, const System::UnicodeString AURIStr, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::Classes::TAsyncCallbackEvent AsyncCallbackEvent, const System::UnicodeString ARequestMethod, const System::UnicodeString AURIStr, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; System::Types::_di_IAsyncResult __fastcall BeginExecute(const System::Classes::_di_TAsyncCallback AsyncCallback, const System::UnicodeString ARequestMethod, const System::UnicodeString AURIStr, System::Classes::TStream* const ASourceStream = (System::Classes::TStream*)(0x0), System::Classes::TStream* const AContentStream = (System::Classes::TStream*)(0x0), const TNetHeaders AHeaders = System::DynamicArray<TNameValuePair>())/* overload */; __classmethod _di_IURLResponse __fastcall EndAsyncURL(const System::Types::_di_IAsyncResult AAsyncResult)/* overload */; __classmethod _di_IURLResponse __fastcall EndAsyncURL(const _di_IURLResponse AAsyncResult)/* overload */; __property int ConnectionTimeout = {read=FConnectionTimeout, write=SetConnectionTimeout, nodefault}; __property int SendTimeout = {read=FSendTimeout, write=SetSendTimeout, nodefault}; __property int ResponseTimeout = {read=FResponseTimeout, write=SetResponseTimeout, nodefault}; __property System::UnicodeString UserAgent = {read=GetUserAgent, write=SetUserAgent}; __property TCredentialsStorage::TCredentialAuthCallback AuthCallback = {read=FAuthCallback, write=FAuthCallback}; __property TCredentialsStorage::TCredentialAuthEvent AuthEvent = {read=FAuthEvent, write=FAuthEvent}; __property TCredentialsStorage* CredentialsStorage = {read=FCredentialsStorage, write=SetCredentialsStorage}; __property TProxySettings ProxySettings = {read=FProxySettings, write=SetProxySettings}; __property System::UnicodeString CustomHeaders[const System::UnicodeString AName] = {read=GetCustomHeaderValue, write=SetCustomHeaderValue}; __property TURLHeaders* CustHeaders = {read=FCustomHeaders}; };

I noticed that System.Net.Mime.pas has a deprecated property/message on it: procedure AddStream(const AField: string; AStream: TStream; const AFileName: string = ''; const AContentType: string = ''; AHeaders: TStrings = nil); overload; deprecated 'Use AddStream with AOwnsStream parameter'; In Delphi, does this show up as a warning if you use this procedure? I didn't get a warning in C++Builder for using it.

If I call it with AOwnsStream=false, it does not crash.

It looks like there was a change to the AddStream - 11.3 left, 12.3 right:

If I step with F7 into everything it eventually comes to this point: If I remark out the one line that uses TMultipartFormData, then the issue does not happen: mfd->AddStream(name, send, value);

Help->About identifies it as 29.0.53571.9782 Delphi 12 and C++ Builder 12 Update 2 I've seen people say there is a GetIt method and I see a: RAD Studio 12.2 Patch 1 1.0 On the products port I see a: RAD Studio, Delphi, C++Builder 12.3 Inline ISO and also a web installer version. RAD Studio 12.2 Patch 2 RAD Studio 12.1 Patch 1 What is the right way to get to 12.3?

Thanks everyone; will do.

The DLL has: #pragma argsused int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { if (reason==DLL_PROCESS_ATTACH) { Application->Initialize(); Form1=new TForm1(NULL); } else if (reason==DLL_PROCESS_DETACH) { if (Form1!=NULL) { delete Form1; Form1=NULL; } } return 1; } The attach section works fine. The Form1 is created and works great. If I omit the cleanup in the detach section, no error, but if I include the above I get the 0x0eedfae exception when closing the application that uses the DLL. Any ideas on why? Could the Form1 have already been deleted/cleaned up before the DllEntryPoint is called with DLL_PROCESS_DETACH?

Thank you everyone; I'll dig into this some more with your ideas.

This is for C++ Builder, but I would think there is a Delphi way to do it that would translate, so I'm asking how you would clear it in Delphi and/or cppb. It says it is "Property Customheaders:UnicodeString", but I can't set it using: nhc->CustomHeaders=""; I am setting it using: nhc->CustomHeaders[name]=value; But, if I want to clear out any custom headers and start again, how do I do that?

Unfortunately there is no Clear() method. When I try to see what the methods are and type c, this is all it shows:

I am building a DLL in cppbuilder 10.2 using the classic compiler with the static RTL. Sometimes I need a component I have available in cppbuilder to be called from microsoft visualc. Mostly this is working - I have a test application where I am opening a form, changing it, closing it, and that works fine. But another part of the application that uses this DLL crashes anytime the DLL is loaded. Even if I don't call any of its functions, just loading it is enough to cause the crash. To make a msvc compatible lib file for it, I also made a sample msvc project with the same function names/declarations that are empty. Then I can use that static lib file in the msvc project that loads the real cppb dll. If I test that empty msvc produced dll, the other part of the application does not crash. I'm trying to test to find out why it crashes. If I do a dumpbin /exports on the msvc empty stub project that just makes the lib, its empty dll shows this. 00000000 characteristics FFFFFFFF time date stamp 0.00 version 1 ordinal base 5 number of functions 5 number of names ordinal hint RVA name 1 0 00001010 displaydialog_dll_close = @_guard_check_icall_nop@4 2 1 00001020 displaydialog_dll_iscanceled = ___acrt_initialize 3 2 00001020 displaydialog_dll_isopened = ___acrt_initialize 4 3 00001010 displaydialog_dll_open = @_guard_check_icall_nop@4 5 4 00001010 displaydialog_dll_update = @_guard_check_icall_nop@4 Summary 1000 .data 1000 .rdata 1000 .reloc 1000 .rsrc 1000 .text Here is the dumpbin /exports from the cppb real dll that I want to use: What are these bold items that are also exported? They are not in my .def file. Section contains the following exports for displaydialog_dll.dll 00000000 characteristics 0 time date stamp 0.00 version 1 ordinal base 11 number of functions 11 number of names ordinal hint RVA name 2 0 00002C4C @@Unit1@Finalize 1 1 00002C34 @@Unit1@Initialize 3 2 00066A10 TMethodImplementationIntercept 6 3 00289B28 _Form1 4 4 0028110C ___CPPdebugHook 5 5 00289B14 dbkFCallWrapperAddr 8 6 00002AD8 displaydialog_dll_close 10 7 00002AE4 displaydialog_dll_iscanceled 11 8 00002AE8 displaydialog_dll_isopened 9 9 00002ADC displaydialog_dll_open 7 A 00002AD0 displaydialog_dll_update Summary 18000 .data 1000 .didata 1000 .edata 4000 .idata 37000 .reloc 8000 .rsrc 280000 .text 1000 .tls Code from my cppb dll: // Important note about DLL memory management when your DLL uses the // static version of the RunTime Library: // // If your DLL exports any functions that pass String objects (or structs/ // classes containing nested Strings) as parameter or function results, // you will need to add the library MEMMGR.LIB to both the DLL project and // any other projects that use the DLL. You will also need to use MEMMGR.LIB // if any other projects which use the DLL will be performing new or delete // operations on any non-TObject-derived classes which are exported from the // DLL. Adding MEMMGR.LIB to your project will change the DLL and its calling // EXE's to use the BORLNDMM.DLL as their memory manager. In these cases, // the file BORLNDMM.DLL should be deployed along with your DLL. // // To avoid using BORLNDMM.DLL, pass string information using "char *" or // ShortString parameters. // // If your DLL uses the dynamic version of the RTL, you do not need to // explicitly add MEMMGR.LIB as this will be done implicitly for you #include <vcl.h> #include <windows.h> #pragma hdrstop #include "Unit1.h" #pragma argsused int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { if (reason==DLL_PROCESS_ATTACH) { Application->Initialize(); //DEBUG i've tried it with and without this no difference still crashes } else if (reason==DLL_PROCESS_DETACH) { } return 1; } //i've tried remarking out all of the below code leaving only the empty function declarations, no difference still crashes //none of these functions even have to be called for it to crash, if the DLL is linked in that is enough extern "C" void __cdecl displaydialog_dll_update(const char *AMessage, const bool ACancelEnabled) { //do nothing if closed if (Form1==NULL) goto end1; //set message Form1->MMessage->Text=AMessage; //set cancelenabled Form1->SBCancel->Enabled=ACancelEnabled; Form1->cancelselected=false; end1: //process messages Application->ProcessMessages(); } extern "C" void __cdecl displaydialog_dll_close() { //do nothing if closed if (Form1==NULL) goto end1; //show form Form1->Close(); //delete form delete Form1; Form1=NULL; end1: //process messages Application->ProcessMessages(); } extern "C" void __cdecl displaydialog_dll_open(const char *AMessage, const bool ACancelEnabled) { //close if opened displaydialog_dll_close(); //create form Form1=new TForm1(NULL); //update message and acancelenabled displaydialog_dll_update(AMessage, ACancelEnabled); //show form Form1->Show(); //process messages Application->ProcessMessages(); } extern "C" bool __cdecl displaydialog_dll_iscanceled() { bool ret; //do nothing if closed if (Form1==NULL) { ret=false; goto end1; } //process messages Application->ProcessMessages(); //is canceled ret=Form1->cancelselected; end1: return ret; } extern "C" bool __cdecl displaydialog_dll_isopened() { bool ret; //do nothing if closed if (Form1==NULL) { ret=false; goto end1; } //process messages Application->ProcessMessages(); //is opened ret=true; end1: return ret; } Yes, I know I could probably come up with a similar solution in msvc, but I am more familiar with cppbuilder. Also, do this same approach with other components from cppbuilder that I also need like tnethtppclient. Any ideas on what to try to troubelshoot this further?

It occurred to me that what is preferred is for the floating point status word to stay the way it was before loading the Embarcadero DLL (newer or older), so I came up with this to be called in the MSVC DLL after all Embarcadero DLL's are loaded. This will set and clear the bits I found to have changed between not loading and then loading the Embarcadero DLL for older or newer compilers. void fix_embarcadero_fpsw() { unsigned int x86_cw; //fix embarcadero changes to floating point status word __control87_2(0x1001c, 0x5001c, &x86_cw, NULL); }

I'm guessing there is something that runs when the DLL is loaded that makes the change. When I was having the original problem, merely doing a LoadLibrary was enough to cause the problem (whether I had a DllEntryPoint function or not). I'm assuming there is some sort of runtime initialization that is executed when the DLL is loaded irregardless of any of its functions being executed. Would this mean that I have to read the floating point value in the code that loads the DLL first (before the DLL is loaded)? And if so, that code is msvc, would I have to use this function to get the value before loading the DLL? https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/control87-controlfp-control87-2?view=msvc-170 In the case of the fix, I had called System::Set8087CW(0x133f); in the DllEntryPoint / DLL_PROCESS_ATTACH to correct it, so this must be after it is changed by the runtime initialization presumably?