Remy Lebeau

I simply mean that properly managing managed fields (strings, interfaces, variants, etc) is an important pro for using Default() vs ZeroMemory(). But, if the type has no managed fields, then it doesn't really matter which one you use, though Default() does make for cleaner code.

Maybe you meant *LESS* error prone? That is a biggy. You don't need heap allocation to get into that situation, but it is harder to do without manually coercing the type system.

The way you are using SetMenuItemInfo() and HiliteMenuItem() in the DropdownMenuShow() method will not work. You are calling them after TPopupMenu.Popup() has exited. Popup() is a blocking method, it does not exit until the popup menu has been dismissed. The TPopupMenu.OnPopup event is fired while Popup() is running. However, upon further review, OnPopup is fired BEFORE the menu is made visible, and TPopupMenu may recreate the menu AFTER OnPopup has been called and BEFORE the menu is actually shown. So, your best bet is likely to subclass the TPopupList window so you can intercept the WM_ENTERMENULOOP message, then customize your menu items at that point. For example: type TPopupListEx = class(TPopupList) protected procedure WndProc(var Message: TMessage); override; end; procedure TPopupListEx.WndProc(var Message: TMessage); begin inherited; if (Message.Msg = WM_ENTERMENULOOP) and (Message.WParam = 1) then begin // customize pmTest items as needed... end; end; initialization Popuplist.Free; //free the "default", "old" list PopupList := TPopupListEx.Create; //create the new one // The new PopupList will be freed by // finalization section of Menus unit. end.

LoadLibrary() will not return anything other than 0 on failure, so if Hinstance_Error is not 0 then checking for it is wrong. When LoadLibrary() does fail, what does GetLastError() say about WHY it failed?

By default, Indy uses OpenSSL. When that error happens, you can use the WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out why. But note that Indy does not support OpenSSL 1.1.x yet, so you would have to deploy OpenSSL 1.0.2 dylibs with your app, and then tell Indy where those dylibs are located at runtime via the IdOpenSSLSetLibPath() function so it can find them. Also look at the IdOpenSSLSetCanLoadSymLinks() and IdOpenSSLSetLoadSymLinksFirst() functions to make Indy avoid loading dylibs for other non-compatible OpenSSL versions. In any case, be aware that ever since Google dropped support for OpenSSL in Android 6 in favor of BoringSSL, using OpenSSL on Android is increasingly difficult. The above MAY OR MAY NOT work, depending on the device's setup. Indy does not support BoringSSL at this time, or any of the more official higher-level Java APIs that Google wants developers to use instead of using lower-level native libraries, like OpenSSL/BoringSSL directly. The alternative is to write your own TIdSSLIOHandlerSocketBase-derived class (or find a 3rd party one) that uses whatever SSL/TLS library/API you want besides OpenSSL. For example, there is some effort in progress to add support for LibreSSL/LibTLS to Indy, though I don't think that will help you in this particular situation, but it shows that supporting alternative SSL/TLS APIs is possible.

The code you have presented does not actually use ANY real functionality from the Sockets unit AT ALL. It is actually using functionality from the WinSock unit instead. So you can just remove the Sockets unit completely, you don't have to replace it with anything. The ONLY things you need to replace are the TSocketHost and TSocketProtocol types. Those are very easy to replace, just re-define them directly in the PCConnectionHelper unit, eg: type TSocketHost = type AnsiString; TSocketProtocol = Word; Or, just drop them completely, they are not actually needed. PCConnectionHelper should just use AnsiString and Word as-is instead. That being said, I do see a number of other problems in your code, particularly in the PCConnectionHelper unit, it is using some unsafe pointer operations that can be made simpler and safer. Maybe that is causing your 64bit issue? But there are some other issues in the IBConnectionHelper unit too, most notably Ansi vs Unicode mismatches. Try these files instead: PCConnectionHelper.pas IBConnectionHelper.pas

That Sockets unit is OLD (dating back to Delphi 6) and is not maintained. That unit was Borland's (before Embarcadero owned Delphi) attempt at providing cross-platform socket classes for Kylix, but it doesn't work very well, and they decided to drop it in favor of Indy in later versions. In fact, that unit is not even distributed with Delphi anymore, XE was the last version to include it. And even if it were still distributed, the 3 class functions you mention never existed in it, not even in 2010, they were always non-static methods of the TIpSocket class, so you could never call them as standalone functions. I'm not quite sure what you are asking for, but you should not be using that Sockets unit in modern projects at all.

TEdit is just a wrapper for a standard Win32 edit control, which does not support vertical alignment, only horizontal.

If you are using an up-to-date version of Indy, the IdSSLOpenSSLHeaders unit has IdOpenSSLSetCanLoadSymLinks() and IdOpenSSLSetLoadSymLinksFirst() functions available. By default, Indy attempts to load unversioned dylibs before loading versioned dylibs. You can turn off this behavior, which is useful in cases where the unversioned dylibs are symlinks to versioned dylibs that are not compatible with Indy. Or, in this case, to turn off the loading of unversioned dylibs altogether.

Code has already been written to do exactly that, actually, but it hasn't been checked in yet.

Then don't use ShowMessage() for that. It displays a modal TForm whose owner window (in Win32 API terms, not VCL terms) is the currently active TForm. An owned window is always on top of its owning window. For what you describe, use a normal TForm instead of ShowMessage(). Set its PopupParent property to the monitoring TForm that needs attention, and then show the popup TForm. This way, the popup Tform stays on top of only its monitoring TForm, but other TForms can appear on top of the popup TForm. Otherwise, change your UI to not use a popup TForm at all. Put a visible message inside the TForm that needs attention.

The TDictionary.Keys property uses a singleton, so no matter how many times you read the Keys property itself, there will only be 1 TKeyCollection object in memory. However, every time you call ToArray() on that collection, it will allocate a new array in memory and populate it with the current keys. Dynamic arrays are reference counted, so every assignment to the local tdictkeys variable will decrement the refcount of the old array, freeing it, and increment the refcount of the new array. When the method exits, the refcount of the last array allocated is decremented, freeing it. If the dictionary is continuously growing in count, then the loop above will allocate larger and larger arrays accordingly, , where a new array is allocated before the previous array is freed. So yes, that has the potential to cause an OOM error over time, depending on just how large the dictionary actually grows. At the assembly level, yes. But if the binary has external dependencies on DLLs/APIs that don't exist on the machine (and modern versions of Delphi's RTL do use APIs that don't exist in Win2K), then the binary will not be loaded by the OS and will not be allowed to run any of its code.

In that TPair record, TKey and TValue are Generic parameters, they belong to the TPair type itself. In C++, that TPair record type gets renamed to TPair__2 because of the Generic parameters. When the Delphi compiler generates a C++ .hpp file, it will declare a constructor inside that type. But since the type is renamed for C++, the HPPEMITs are being used to provide an implementation for that constructor using the new name. I have never seen the [HPPGEN] attribute before, though. It is not documented.

(copied from my answer to your same question on StackOverflow😞 Indy is not really designed for peeking data, it would rather that you read whole data, letting it block until the requested data has arrived in full. That being said, TIdBuffer does have a PeekByte() method: function PeekByte(AIndex: Integer): Byte; var B: Byte; if AContext.Connection.IOHandler.InputBuffer.Size > 0 then begin B := AContext.Connection.IOHandler.InputBuffer.PeekByte(0); ... end; Or, if you are looking for something in particular in the buffer (ie, a message delimiter, etc), TIdBuffer has several overloaded IndexOf() methods: function IndexOf(const AByte: Byte; AStartPos: Integer = 0): Integer; overload; function IndexOf(const ABytes: TIdBytes; AStartPos: Integer = 0): Integer; overload; function IndexOf(const AString: string; AStartPos: Integer = 0; AByteEncoding: IIdTextEncoding = nil {$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF} ): Integer; overload; var Index: Integer; Index := AContext.Connection.IOHandler.InputBuffer.IndexOf(SingleByte); Index := AContext.Connection.IOHandler.InputBuffer.IndexOf(ArrayOfBytes); Index := AContext.Connection.IOHandler.InputBuffer.IndexOf('string'); ...

No, there is not.

You can hexdump each compiler EXE to see which conditional symbols are actually available. That is what I do sometimes.

Yes, if you can't specify the actual TKey/TValue Generic parameters up front at compile-time when defining how you access the dictionary object from the Sytem.Rtti.TValue record. In which case, you can't use a standard "for..in" loop to enumerate the dictionary. All the necessary type information is lost once you access the dictionary object via the System.Rtti.TValue record if you can't type-cast the object. So yes, this is the only way I can think to enumerate the dictionary object using only RTTI and not caring what the actual Generic parameters are. I mean, if you really needed the RTTI for those types, you could take the dictionary object's ClassName() string, parse the typenames between the angle brackets, and resolve them using TRttiContext.FindType(), but that won't help you to enumerate the dictionary at all since you still need access to its enumerators (either via its GetEnumerator() method or its Keys+Values properties). I really couldn't say. Probably not, if you use the RTTI correctly and handle the enumeration correctly. Hopefully the RTTI and Sytem.Rtti.TValue record will handle the complexities for you. It doesn't, outside of the implementation code for the TDictionary class, where the TKey and TValue Generic parameters have meaning. Outside of the class, they don't exist. They are part of the class type itself, for instance TDictionary<string, int> and TDictionary<int, char> are separate and distinct types with no relation to each other. No. {$HPPEMIT} has no effect whatsoever on how the Delphi compiler processes code. {$HPPEMIT} merely outputs an arbitrary line of text to a C++ .hpp header file, if one is being generated while the Delphi compiler is parsing the code. Curious - what version of Delphi are you using? I have RTL sources up to XE3, and there are no {$HPPEMIT} statements at all in System.Generics.Collections.pas in those versions, so it must be something added in more recent versions.

Generics are not easy to serialize manually because of the nature of their dynamic types. You will likely have to resort to something like the following (untested, but should give you an idea of what is involved): var mc: TMClass; ctx: TRttiContext; rType: TRttiType; rProp: TRttiProperty; rMethod: TRttiMethod; rKeyField, rValueField: TRttiField; propValue, methValue, genKey, genValue: TValue; genDict, genDictEnum: TObject; genPair: Pointer; begin mc := TMClass.Create; try { if Assigned(mc.MC) then begin for var pair in mc.MC do begin // use pair.Key and pair.Value as needed ... end; end; which is actually this behind the scenes ... if Assigned(mc.MC) then begin var enum = mc.MC.GetEnumerator; while enum.MoveNext do begin var pair = enum.Current; // use pair.Key and pair.Value as needed ... end; end; } rType := ctx.GetType(mc.ClassInfo); // rType = TMClass rProp := rType.GetProperty('MC'); propValue := rProp.GetValue(mc); genDict := propValue.AsObject; if Assigned(genDict) then begin rType := rProp.PropertyType; // rType = TObjDict rMethod := rType.GetMethod('GetEnumerator'); methValue := rMethod.Invoke(genDict, []); genDictEnum := methValue.AsObject; rType := rMethod.ReturnType; // rType = TDictionary<TKey, TValue>.TPairEnumerator rMethod := rType.GetMethod('MoveNext'); rProp := rType.GetProperty('Current'); rType := rProp.PropertyType; // rType = TPair<TKey, TValue> rKeyField := rType.GetField('Key'); rValueField := rType.GetField('Value'); methValue := rMethod.Invoke(genDictEnum, []); while methValue.AsBoolean do begin propValue := rProp.GetValue(genDictEnum); genPair := propValue.GetReferenceToRawData; genKey := rKeyField.GetValue(genPair); // genKey.TypeInfo = TypeInfo(string) genValue := rValueField.GetValue(genPair); // genValue.TypeInfo = TypeInfo(string) // use genKey and genValue as needed ... methValue := rMethod.Invoke(genDictEnum, []); end; end; finally mc.Free; end; end. Because it doesn't exist. For a dictionary, TKey and TValue are Generic parameters of the TDictionary class. They are not standalone concrete types, like you are thinking of.

You have a mismatch in your code: Do you see it? String <> TValue. You need to fix your declaration of the genDict variable to match the TObjDic type. In fact, why are you not using TObjDict itself in the declaration of genDict? type TObjDic = TObjectDictionary<string, string>; ... var ... genDict: TObjDic; begin ... genDict := propvalue.AsObject as TObjDic; ...

Then please show your actual code. It sounds like you are trying to instantiate TKey objects, which you should not be doing at all. You don't need to create a TKey object in order to enumerate a TDictionary. Use the TDictionary.Keys and TDictionary.Values properties, or the TDictionary.GetEnumerator() method.

I imagine trying to access the content of a TDictionary via RTTI will be very difficult, if not down-right dangerous due to the extra work needed to deal with managed types and such. You would be better off simply retrieving the TDictionary object pointer from the property (ie, using "propvalue.AsType<TDictionary<TKey, TValue>>" or "propvalue.AsObject as TDictionary<TKey, TValue>") and then access its content via normal TDictionary methods, not via RTTI at all.

Unlike in 32bit, multiple calling conventions simply do not exist in 64bit. There is only 1 calling convention, and it is dictated by the 64bit ABI itself. Keywords like 'cdecl' and 'stdcall' are ignored when compiling for 64bit, so as not to break code that is being ported from 32bit.

I hope your class never gets used in C++, because the resulting constructors would have the exact same names and parameter lists, and thus be ambiguous and unusable!

Are the TIdHTTP.BoundIP and TIdHTTP.BoundPort(Min|Max) properties set to '' and 0, respectively? When the error happens, what is the actual value of the TIdHTTP.Socket.Binding.IP, TIdHTTP.Socket.Binding.Port, and TIdHTTP.Socket.Binding.ClientPort(Min|Max) properties? They should also be '' and 0, respectively. If they are not, then something weird is going on. By default, TIdHTTP should be binding to local port 0, allowing it to use a random local ephemeral port assigned by the OS. There should be no "address and port already in use" error for just 10 connections if they are all on random local ports. Which implies that there may be a non-zero port being used explicitly somewhere.

Are you reusing the same TIdHTTP object for multiple Get() calls? Unless you are explicitly setting the TIdHTTP.BoundPort(Min|Max) properties, I don't see any other way you can get that error, unless you are creating so many connections that you are just exhausting the OS's available local ports over time. Possibly. Hard to say without seeing your actual code, or at least knowing how many threads you are using.