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.

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

>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 found it under manage features - thanks.

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?

>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};
};

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?

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);

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?

Thanks everyone; will do.

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:

and also a web installer version.

RAD Studio 12.2 Patch 2

What is the right way to get to 12.3?

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

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?

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

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?

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?

You have figured it out Remy!!!  Good work!  Superb!!!  Thank you!

I added System::Set8087CW(0x133f) to my DLL and rebuilt it in 10.2 - no crash.  Remark it out, back to the crash.

This brings up a question #1 - is the original value (whatever it was set to before loading the DLL changes it) stored somewhere (could it be Saved8087CW)?  I'm not sure I'd want a DLL changing the floating point behavior of a program just because it is loaded.

Also, should I do an Application->Initialize() or not in the DllEntryPoint/atttach?  Question #2 - What does Application->Initialize() do?

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
  if (reason==DLL_PROCESS_ATTACH)
    {
      //Application->Initialize();
      //Application->MessageBox(L"test",L"test",MB_OK);

      System::Set8087CW(0x133f);

    }
  else
  if (reason==DLL_PROCESS_DETACH)
    {
    }
  return 1;
}