Remy Lebeau

That sounds like a lot of extra work for very little gain. I don't think it is very good design to expose design-time access to sub-property events. The sub-properties are part of the main component. All events should be part of the main component, as well. But that is just my opinion.

That's like the very definition of Undefined Behavior. Accessing the array out of bounds is reaching into surrounding memory, and the content of that memory is random/indeterminate on each new run. It could be random bytes left over from a previous run/process. It could be bytes belonging to other local variables on the stack. You just don't know. myArray[2] = 7 myArray[4] = 9 myArray[7] = out of bounds, UB! myArray[8] = out of bounds, UB! myArray[9] = out of bounds, UB!

Which is what, exactly?

That was my first instinct too, but it doesn't work. I tried it.

The Object Inspector does not display events for nested sub-properties. It can only display the events that are directly members of the selected object(s), which in this case is your TTest component, not the TTestSub nested sub-object. All of the events need to be exposed only at the top-level of your TTest component. If you have sub-property events you want to expose in the OI, you will have to propagate them accordingly, eg: unit FooBar.Reg; interface uses Classes, DesignIntf; type TTestSub = class(TPersistent) private FOnEvent: TNotifyEvent; FTest: string; public procedure Assign(Source: TPersistent); override; published property Test: string read FTest; property OnTestEvent: TNotifyEvent read FOnEvent write FOnEvent; end; TTest = class(TComponent) private FSub: TTestSub; procedure SetSub(const Value: TTestSub); function GetOnTestEvent: TNotifyEvent; procedure SetOnTestEvent(AValue: TNotifyEvent); public constructor Create(AOwner: TComponent); override; destructor Destroy; override; published property Sub: TTestSub read FSub write SetSub; property OnTestEvent: TNotifyEvent read GetOnTestEvent write SetOnTestEvent; end; procedure Register; implementation procedure Register; begin RegisterComponents('FooBar', [TTest]); end; { TTest } constructor TTest.Create(AOwner: TComponent); begin inherited; FSub := TTestSub.Create; FSub.FTest := 'Hello world'; end; destructor TTest.Destroy; begin FSub.Free; inherited; end; function TTest.GetOnTestEvent: TNotifyEvent; begin Result := FSub.OnTestEvent; end; procedure TTest.SetOnTestEvent(AValue: TNotifyEvent); begin FSub.OnTestEvent := AValue; end; procedure TTest.SetSub(const Value: TTestSub); begin FSub.Assign(Value); end; { TTestSub } procedure TTestSub.Assign(Source: TPersistent); begin FOnEvent := TTestSub(Source).OnTestEvent; end; end. I could be wrong, but I don't recall this ever being possible. Apples and Oranges. What you are asking for is simply not supported by Delphi without propagating the events manually, or maybe by writing a custom property/component editor that exposes nested events at the top level.

Accessing an array out of bounds is Undefined Behavior. Anything can happen. An AV/exception is not guaranteed. C++ does not have bounds checking on vanilla C-style arrays. If you want that, switch to std::array or std::vector and use their at() method. In this particular example, the first few array values are valid indexes into the array, and the remaining values are small enough that the code would exceed the bounds of the array into surrounding memory but stay within the bounds of the calling thread's stack, It's valid memory access as far as the OS is concerned, thus no AV is thrown, but it's still Undefined Behavior as far as C++ is concerned.

Pointers are implicitly convertible to bool. A string literal is not itself a pointer, but it does decay into a pointer, which is then convertible. Note that NULL is not a pointer. It is an alias for a null pointer constant, either nullptr or integer literal 0 (depending on implementation), which can be assigned to any pointer.

Indy in general (not just TIdSMTP specifically) indeed natively supports only up to OpenSSL 1.0.2, not OpenSSL 1.1.x and later. This is a LONG standing problem with no resolution in Indy itself at this time. But, there are a few 3rd party implementations available that add support for those versions, such as TaurusTLS: https://github.com/JPeterMugaas/TaurusTLS

Got an interesting reply on the ticket: He meant this deprecated method instead: procedure AddStream(const AField: string; AStream: TStream; const AFileName: string = ''; const AContentType: string = ''; AHeaders: TStrings = nil); overload; deprecated 'Use AddStream with AOwnsStream parameter'; 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. So, do the conversion explicitly and then you will hopefully see the warning: mfd->AddStream(_D("name"), send, String(_D("value")));

Got a reply on my ticket: Yes

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. It is the last line of this: ... On the closing '};' of the class? 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.

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 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): // CLANG vs. BCC attributes #if !defined(__clang__) ... #define _DEPRECATED_ATTRIBUTE0 [[deprecated]] #define _DEPRECATED_ATTRIBUTE1(msg) [[deprecated]] // Ignore message as bcc's implementation is capped:( #define _DEPRECATED_ATTRIBUTE2 [[deprecated]] #define _DEPRECATED_ATTRIBUTE3(msg) [[deprecated]] // Ignore message as bcc's implementation is capped:( ... #else ... #define _DEPRECATED_ATTRIBUTE0 // Could use __attribute__((deprecated)) #define _DEPRECATED_ATTRIBUTE1(msg) // Could use __attribute__((deprecated( msg ))) #define _DEPRECATED_ATTRIBUTE2 __attribute__((deprecated)) #define _DEPRECATED_ATTRIBUTE3(msg) __attribute__((deprecated( msg ))) ... #endif 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 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).

Precompiled header being compiled only 1 time? Is it perhaps 7 messages for 7 different translation units (.cpp files) that are using the same header? Each translation unit is compiled independently, so output messages are not consolidated across TUs. What does line 772 actually look like?

In <System.Net.Mime .hpp>, is there a 'deprecated' attribute on the declaration of AddStream()? Also, which C++ compiler(s) are you using, exactly? The DocWiki says only the classic bcc32 compiler supports deprecated messages.

Have you tried TPath.GetCameraPath() yet? Does your app have permission to access the camera files?