Remy Lebeau

Yes, but you did that using Indy's master code, which only had bug fixes and new package files. Try it again with branched code that has interface changes in it, and you may have a different result.

More accurately, there are some interface changes to the base TIdSASL class and the TIdSASLMechanisms class, which affects several Indy components that use SASL, including TIdPOP3, TIdSMTP, TIdIMAP4, and TIdDICT. Yes, but that's not going to happen until the branch is merged into the master code. Embarcadero doesn't ship branched code.

The new OAuth SASL classes are not compatible with the pre-bundled Indy version. The sasl-oauth branch contains some interface changes, to add an APort parameter to the SASL process. Unfortunately, not.

When I try this step in Delphi 12, there are only 16 files TOTAL listed: - 8 starting with FMX - 8 starting with VCL All 8 are Indy files (and all of them are related to IdAntiFreeze), there are no "play" files, no "idoc.dcu" or "idispids.dcu" files, etc. I'm guessing the missing files are platform-specific files, in which case this step is dependent on the configuration chosen when you install the IDE. I don't have any non-Windows platforms installed. I'll have to figure out a way to filter out the non-Indy files so they don't get auto-deleted by accident.

It should not be ambiguous. Indy uses the LocaleCharsFromUnicode() function that Delphi provides in the System unit. The IdGlobal unit defines its own version of that function only if Delphi's version doesn't exist. So there should be no such function defined in the IdGlobal unit in Delphi 12. If there is, then something is wrong. The DPKs don't provide the conditionals that Indy uses. They are all defined in IdCompilerDefines.inc which is included by the individual .pas files.... OH, yeah, the branch wasn't up-to-date with the latest .inc file yet. I have updated the branch with the latest master code for Delphi 12.

No, the spelling is correct. If you remove the preinstalled version of Indy then LivePreview/EMSEdge projects will break, but "you CAN use a SEPARATE installation of Indy 10 for non-LivePreview/EMSEdge projects" if you need to use multiple Indy versions. I don't have an ETA on that. The code is pretty much done for now, but it is an interface change as there is an extra parameter added to the SASL login procedures. And also, I don't have palette icons for the new OAuth SASL components yet.

Correct, there is no event published for this. You would have to subclass the ListView to handle the HDN_ITEMCHANGING notification directly. Alternatively, if you are building with Runtime Packages disabled, you can make a copy of Vcl.ComCtrls.pas and add it to your project, and then make the code change I mentioned earlier to fix the bug.

In this example, yes. Like strings, dynamic arrays are also reference-counted. When you nil a reference to a dynamic array, its refcount is decremented. When its refcount falls to 0, its contents are finalized as needed (to release their references, etc), and the array is freed from memory.

Multiple versions of Indy can't be installed in the IDE at the same time. You would have to maintain separate copies and switch between them on a per-project basis as needed. Also, TIdSASLXOAuth2 is not in the master code, it is still in a sasl-oath branch that hasn't been merged yet.

That is not a good idea. Such an indicator should not be in the data payload itself, it should precede the payload, ie in a separate message header. Also, to differentiate between UTF8 or UTF16, you could use standard Unicode BOMs. So, for instance, have a message header that indicates whether the payload is text bytes or file bytes, and the total byte size. Then in the payload itself, if it is text then have it start with a BOM before the actual text bytes. Although, in reality, it is generally not a good idea to use UTF16 in data transmissions. Better to stick with just UTF8. Convert to/from UTF16 in memory only, if needed.

Which files does it delete that it shouldn't? Oh. Nevermind.

https://docwiki.embarcadero.com/RADStudio/en/FireUI_Live_Preview

I just now closed the PR and checked in my own changes for Delphi 12.

In XE7 and later, you should use the GetTypeKind() intrinsic function instead of using TypeInfo() comparisons: https://delphisorcery.blogspot.com/2014/10/new-language-feature-in-xe7.html case GetTypeKind(T) of tkInteger: PInteger(@Result)^ := 10; tkLString: PAnsiString(@Result)^ := 'Hello'; tkUString: PUnicodeString(@Result)^ := 'Hello'; ... end;

Your getUSBDeviceInfo() function requires a symbolic name containing at least 2 '#' chars in it, but the ports you are testing with don't have any '#' chars in their names at all. When your TButton.OnClick handler calls FindPorts(), it gets the device list and checks each device name with ContainsMediaTekPort(). You are recording the result of that check to the log file, which is why you see the device being found. And then, if a matching name is found then the subsequent call to getUSBDeviceInfo() fails to parse the device name, thus skipping the retrieval of that device's info from the Registry. Your OnClick handler is then looping through the returned device array, checking each device's PortName for the device name (which in of itself is wrong since the PortName is different than the device name), and since the PortName was never being populated, that is why you see the "not found" error. You should have been able to discover this problem for yourself if you had stepped through your code with the debugger line-by-line and noticed that getUSBDeviceInfo() was never reading from the Registry. You need to fix this parsing problem so that getUSBDeviceInfo() actually returns the data you are expecting. Aside from that, just from a design perspective, I would strongly recommend changing FindPorts() to NOT include 'default' entries in the returned array. When you are filtering for a specific type of port, that is all you should be returning, eg: Function FindPorts(Filter: string = ''): TUSBDeviceList; var sub: TStringList; i: integer; begin sub := TStringList.Create; try FindAvailableCOM(sub); if Filter <> '' then begin for i := sub.Count - 1 downto 0 do begin if Pos(Filter, sub[i]) = 0 then sub.Delete(i); end; end; SetLength(Result, sub.Count); for i := 0 to sub.Count - 1 do Result[i] := getUSBDeviceInfo(sub[i]); finally sub.Free; end; end; ... procedure TForm13.Button3Click(Sender: TObject); var Ports: TUSBDeviceList; begin Ports := FindPorts('MediaTek USB Port_V1633'); if Length(Ports) > 0 then begin LogPortCheckingInfo('MediaTek port found: ' + Ports[0].DeviceParameters.PortName); ShowMessage('MediaTek port found.'); end else begin LogPortCheckingInfo('MediaTek port not found.'); ShowMessage('MediaTek port not found.'); end; end; Now, all of that being said, I do also notice a number of other mistakes and general problems with the code you have provided, such as lack of adequate error handling, use of incorrect data types, etc. It could really benefit from a good code review and cleanup in general.

I'm guessing you didn't see https://github.com/IndySockets/Indy/pull/517 yet? In any case, I'm also working on my own update to Indy for D12, but that update also includes bringing Indy's Package Generator up-to-date, which is why I haven't merged the above PR yet, as I want to see how the generated files compare to the PR's files. Although, I guess at this point, I should just merge the PR and then merge in any generator diffs later...

TListItem does not have a MinWidth property, you meant TListColumn instead. In any case, what version of Delphi are you using? I can reproduce the problem in Delphi 12 w/ Patch 1 installed. When dragging a column divider in the header, the TListColumn.MinWidth and TListColumn.MaxWidth values get ignored when the TListView is processing an HDN_ITEMCHANGING notification from the header. TListView looks for HDN_ITEMCHANGING to trigger a redraw of the active TListItem, but there is an 'else' that skips the MinWidth/MaxWidth processing: if (Mask and HDI_WIDTH) <> 0 then begin if code = HDN_ITEMCHANGING then EnsureItemRedrawn(nil) else // <-- HERE!! begin Col := GetColumnFromTag(Item); if Col.MinWidth >= cxy then cxy := Col.MinWidth else if (Col.MaxWidth > 0) and (Col.MaxWidth <= cxy) then cxy := Col.MaxWidth; Col.Width := cxy; end; end; When I take that 'else' out, the MinWidth/MaxWidth values work properly as expected: if (Mask and HDI_WIDTH) <> 0 then begin if code = HDN_ITEMCHANGING then EnsureItemRedrawn(nil); //else // <-- HERE!!! begin Col := GetColumnFromTag(Item); if Col.MinWidth >= cxy then cxy := Col.MinWidth else if (Col.MaxWidth > 0) and (Col.MaxWidth <= cxy) then cxy := Col.MaxWidth; Col.Width := cxy; end; end; This bug does not exist in Delphi 10.3, so it was introduced sometime after that version: if (Mask and HDI_WIDTH) <> 0 then begin // NO redraw LOGIC HERE!!! Col := GetColumnFromTag(Item); if Col.MinWidth >= cxy then cxy := Col.MinWidth else if (Col.MaxWidth > 0) and (Col.MaxWidth <= cxy) then cxy := Col.MaxWidth; Col.Width := cxy; end; I would suggest filing a bug report with Embarcadero, but Quality Portal is still down. I'll report it privately.

That is a LOT of code to go through, I'm betting most of it is irrelevant to the problem at hand. And it doesn't even include your UI code that is displaying the "not found" error, so I don't even know which portions of this code are actually being exercised.

Your formatting is all messed up, please fix it.

Why does your device manager keep refreshing and showing the port disappearing? Are you perhaps opening the port during the time it has disappeared? What does your code look like that is opening the port?

Look for the tfVerificationFlagChecked flag in the TTaskDialog.Flags property after TTaskDialog.Execute() returns true: if TaskDialog.Execute then begin ... Result.DoNotShowAgain := tfVerificationFlagChecked in TaskDialog.Flags; ... end And, if you want the checkbox to be initially checked when you display the dialog, enable the tfVerificationFlagChecked flag before calling TTaskDialog.Execute(): TaskDialog.Flags := [tfUseCommandLinks, tfAllowDialogCancellation, tfExpandFooterArea]; if DoNotShowAgainIsChecked then TaskDialog.Flags := TaskDialog.Flags + [tfVerificationFlagChecked];

You can configure the IDE to not break on exceptions. I usually use breakpoints to tell the debugger to not break on exceptions that occur within specific sections of code I don't want to break on.

The information you are looking for is not compiled into the EXE/DLL itself. Tools like IDR exist to heuristically analyze an EXE/DLL and compare its signature to a database of known compiler versions. How to detect Delphi compiler version in which exe was compiled?

If the code is expecting a debugger to attach, I would just call IsDebuggerPresent() in a sleep loop until it returns true or times out.

You can't, as there is no way to get from the MenuHandle/HMENU to its dialog window. However, there can only be 1 menu active at a time, so you should be able to use FindWindow/Ex() to find the HWND of the active menu whose window class name is "#32768"/MAKEINTATOM(0x8000), Once you have the menu's HWND, you should be able to use GetWindowRect() to get its position and size.