Remy Lebeau

W1037 FOR-Loop variable '%s' may be undefined after loop (Delphi) Also see: What is The Loop Variable After a For Loop in Delphi?

I just now checked, this code exists in TListColumn.DoChange() all the way back to at least Delphi 5 (that the oldest version I have VCL source code for)!

Sorry, but you are not on the right track, not even close. You can't pass a message ID to SetWindowsHookEx() like you are doing. The 1st parameter expects a hook type (one of the WH_... constants), not a message ID. To hook window messages, you need to specify either the WH_GETMESSAGE or WH_CALLWNDPROC/RET hook type, and then look for your desired message ID inside of your hook callback function. However, in this particular situation, CM_VISIBLECHANGED is a private message to the VCL only, it does not go through the Win32 messaging system at all, so a SetWindowsHookEx() hook will never see it. The only way you can intercept CM_VISIBLECHANGED is to either: subclass the WindowProc property of every TControl you are interested in. derive your own UI classes that either override the virtual WndProc() or DefaultHandler() method, or define a 'message' handler for CM_VISIBECHANGED. use a detouring library, such as MSDetours, to hook into the non-virtual TControl.Perform() method directly (which is what the TControl.Visible property setter calls to send out CM_VISIBLECHANGED). This won't help you in this particular situation, but in general to retrieve the relevant HWND in a SetWindowsHookEx() hook: for WH_GETMESSAGE, the lParam is a pointer to a MSG structure, which has an HWND member. for WH_CALLWNDPROC, the lParam is a pointer to a CWPSTRUCT structure, which has an HWND member. for WH_CALLWNDPROCRET, the lParam is a pointer to a CWPRETSTRUCT structure, which has an HWND member.

Why not use the ClassType instead of the ClassName? GetProperties(v_FDConnection.Params.ClassType); GetClass() only returns classes that are registered with RegisterClass(). Not all classes are registered. GetClass() returns nil if it can't find the requested class. You are not handling that possibility. You can't pass nil to TRTTIContext.GetType(). FindClass(), on the other hand, will raise an EClassNotFound exception if the requested class is not found.

What makes you think EnumModules() has anything to do with that list? It enumerate the modules that your compiled EXE is using at runtime. Not the modules that are installed in the IDE at design-time. If you want the list that is installed in the IDE, then you will have to manually read that list from the IDE's configuration in the Windows Registry. If you want the list that your EXE is compiled with, then such modules only exist if you compile with Runtime Packages enabled so the packages are used as external BPLs at runtime.

Arbitrary components don't have a Parent. TComponent does not have a SetParent() method. So, unless CreateComponent() is using RTTI, it won't have any knowledge of your custom SetParent() method. And it certainly won't be able to call it since it won't have access to TMyParentComponent. Only TControl-derived components have a Parent. I expect CreateComponent() to check if the specified class type is a TControl descendant, and if so then cast the created object to TControl in order to set its TControl.Parent property, as well as its TControl.Left/Top/Width/Height properties (probably by calling TControl.SetBounds()).

Yes, it does. And has done so for a VERY VERY LONG time, long before the "manifest file and a setting in the registry" you refer to ever existed. https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces NTFS is such a file system, which has been supported since Windows 3.1, though long paths were not supported on it until Windows 95. MAX_PATH is an artificial limitation of the Win32 API, not of the file system. The more commonly referred documention about this is: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation The "manifest file and a setting in the registry" that you refer to simply allows an app to use such long paths without needing to use the "\\?\" prefix anymore.

Does your program use external DLLs/BPL files? Even if you are using Packages, if they are statically linked into your EXE then they will probably not be treated as separate modules.

Good catch! Per RFC 7540: https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.4

Because you are using it incorrectly. They are the same address, but they are not the same type. The Params is holding a ^^TParamEmbedded (a pointer to a pointer to a record), but ParamEmbeddedRec is a ^TParamEmbedded (pointer to a record) instead. The only reason your code even compiles at all is because the Params is an untyped Pointer, so all type safety is out the window. You are correct. You are storing a ^^TParamEmbedded into the Params, and then accessing it back out as a ^TParamEmbedded instead, eg: +------------+ +------------+ | Operacao | | PatchParam | | Params |---+ | Payoad | +------------+ | +------------+ ^ | ^ | | | +-------------+ | +---------------+ +------------------+ | ParamMaster | +-->| ParamEmbedded |<----| ParamEmbeddedRec | +-------------+ +---------------+ +------------------+ Get rid of the @, you don't need it since the ParamEmbedded variable is already a pointer, eg: procedure TForm1.Button1Click(Sender: TObject); Type TParamMaster = Record Operacao : Smallint; Params : Pointer; End; TParamEmbedded = Record PatchParam : String; Payload : String; End; Var ParamMaster : ^TParamMaster; ParamEmbedded : ^TParamEmbedded; ParamEmbeddedRec : ^TParamEmbedded; begin New(ParamMaster); New(ParamEmbedded); ParamEmbedded.PatchParam := 'somePatch'; ParamEmbedded.Payload := '{"aooCode": "F60EB930-9B1B-11EF-9657-02240D86274B"}'; ParamMaster.Operacao := 1; ParamMaster.Params := ParamEmbedded; // <-- NO @ HERE! ParamEmbeddedRec := ParamMaster.Params; ... Dispose(ParamEmbedded); Dispose(ParamMaster); end; +------------+ +------------+ | Operacao | | PatchParam | | Params |------->| Payload |<----------+ +------------+ +------------+ | ^ ^ | | | | +-------------+ +---------------+ +------------------+ | ParamMaster | | ParamEmbedded | | ParamEmbeddedRec | +-------------+ +---------------+ +------------------+ That being said, this example can be simplified by not using New/Dispose at all, in which case using @ does make sense, eg: procedure TForm1.Button1Click(Sender: TObject); Type TParamMaster = Record Operacao : Smallint; Params : Pointer; End; TParamEmbedded = Record PatchParam : String; Payload : String; End; Var ParamMaster : TParamMaster; ParamEmbedded : TParamEmbedded; ParamEmbeddedRec : ^TParamEmbedded; begin ParamEmbedded.PatchParam := 'somePatch'; ParamEmbedded.Payload := '{"aooCode": "F60EB930-9B1B-11EF-9657-02240D86274B"}'; ParamMaster.Operacao := 1; ParamMaster.Params := @ParamEmbedded; // <-- DO USE @ HERE! ParamEmbeddedRec := ParamMaster.Params; ... end; ParamMaster ParamEmbedded +------------+ +------------+ | Operacao | | PatchParam | +------------------+ | Params |---->| Payload |<----| ParamEmbeddedRec | +------------+ +------------+ +------------------+

Do you have the same problem if you use the WinInet API instead of the WinHTTP API? In any case, at this point does it really matter if the status text is being returned or not? It is arbitrary text determined by the server, so you shouldn't rely on it for any kind of processing logic, only for logging at best. What is important is whether the status code works or not, and it sounds like it does.

Yes, unless you have access to the server's private key. Which is why I also mentioned Fiddler, which acts as a proxy and can capture HTTPS.

Then you should open a ticket with Embarcadero asking for that.

Prior to Delphi 12, the Enum type for TShiftState is anonymous, so you can't declare a variable of that type, at least not directly. With the introduction of Inline Variables and Type Inference in Delphi 10.3, you can do so, but only if you initialize the variable at the same time you declare it, eg: var state := ssShift; This is exactly the kind of situation why several such Sets in the RTL have been re-written in recent versions to separate their Enum types from their Set types. TShiftState was re-written in Delphi 12, it now looks like this: TShiftStateItem = (ssShift, ssAlt, ssCtrl, ssLeft, ssRight, ssMiddle, ssDouble, ssTouch, ssPen, ssCommand, ssHorizontal); TShiftState = set of TShiftStateItem; So, you can now declare a variable of type TShiftStateItem.

It does. When it is called the 1st time with a nil buffer and 0 size, it returns the actual buffer size that is needed, which would include room for the null terminator. On the 2nd call, when the buffer is actually filled in, it returns the number of bytes actually written into the buffer, not counting the null terminator, but the actual null terminator is written. A lot of Win32 APIs work this way. Then either the "OK" text is not actually on the response, or the API is broken. That would imply a bug in the API that would need to be reported to Microsoft. The API doesn't provide the complete raw response, only pieces of it. You would have to use a packet sniffer like Wireshark or Fiddler to capture the complete raw response.

Throwing exceptions across the DLL boundary in a vanilla DLL is NEVER a good idea, regardless of compiler version. Just don't do it. That can only work in a Package instead of a DLL, but then you can't use a Package across different Delphi versions.

Maybe related to the change in default Floating-Point exception flags in Delphi 12? https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms

More like (O#0K#0#0#0) if you are looking at raw bytes. But yes, it should be 6 bytes (2 wide chars + 1 wide null terminator) since the Unicode version of WinHTTPQueryHeaders() is being called. Correct. And since the Result is a String, the SetLength() will actually allocate memory for a null terminator even though it is not being requested in the size. So, the code should be calling SetLength(2) for 'OK' but it will allocate memory for 3 Chars, enough for WinHTTPQueryHeaders() to fill in.

You should not need to add the .pas file, just enable Debug DCUs instead, then you can step into the RTL's source code. Are you compiling for 64bit? Do you have all patches installed? Inspecting Delphi variables in C++ is a known issue. Hard to say without knowing what the true value of LSize is. Sounds more like LSize may be 0-2 bytes to begin with. That is pretty large for a 200 reply. Most servers just send an "OK" text. What does the raw response line actually look like on the wire? That should not be possible. If the specified length is greater than 0 then memory is guaranteed to be allocated or an exception thrown on failure. Personally, I would not have coded it the way they did. If WinHTTP asks for a buffer allocation then I would just make the 2nd API call unconditionally after allocating the requested memory. It looks like they are trying to ignore the case where the text is empty (just a null terminator), in which case they should have tested the requested LSize before allocating the memory. But that is just me. That attachment can't be found.

Again, can you provide the actual XML? The error message is complaining about an invalid character. Non-ANSI characters on their own are not invalid characters in XML, but certain characters in certain contexts may be. For instance, text elements do not allow Unicode codepoints in the range of control characters and surrogates. We need more information to diagnose the problem. SOAP uses well-defined XML. So, either your server is not sending valid XML correctly, or more likely you are just not parsing it correctly. Also, to be clear - you are not getting an Access Violation. You are getting a Parsing error. Those are two different things. Then the encoding is probably not correct to begin with. Are you receiving and saving/parsing the XML as a string, or as raw bytes? You should be doing the latter, not the former.

One thing to note - ReadHeaders() calls WinHttpQueryHeaders(), but WinHttpQueryHeadersEx() is documented as not accepting WINHTTP_QUERY_STATUS_TEXT, so maybe Microsoft made an update that affects WinHttpQueryHeaders() similarly and didn't document it? Just guessing. What does that have to do with retrieving the status text? It doesn't come from those headers.

Or that! ☝️ Which is basically the same as ToJSON() with all options turned off.

This has nothing to do with the TRESTClient itself. You are receiving the response, parsing it into a TJSONObject, and then converting its child data back into a JSON formatted string. What you are seeing is the JSON encoding. By default, ToJSON() encodes non-ASCII Unicode characters in '\uXXXX' format: function TJSONAncestor.ToJSON: string; begin Result := ToJSON([TJSONOutputOption.EncodeBelow32, TJSONOutputOption.EncodeAbove127]); end; To avoid that, you will have to directly call the ToJSON() overload that accepts a TJSONOutputOptions parameter so you can omit the EncodeAbove127 (and EncodeBelow32) flag, eg: (myResponse.JSONValue as TJSONObject).GetValue('objectProperty1').ToJSON([]) // <-- note the brackets!

Do you mean the XML prolog? can't you just add one if it is missing before you parse the XML? What's wrong with that? And? Xml supports Unicode characters. Any conformant XML parser will handle that. By default, it uses MSXML on Windoes. But, you can change the library used, via the DOMVendor property. Can you provide an example XML that you are having trouble with?

TDrawGrid is derived from TWinControl, whereas TImage is derived from TGraphicControl. Both controls in your DFM have the same Parent (the Form). A graphical control is rendered directly onto the canvas of its Parent, and thus can never appear on top of a child windowed control of the same Parent. As suggested earlier, you will have to make the TImage be a child of the TDrawGrid, or put the TImage on a separate Form (or Frame) that is on top of the TDrawGrid.