Remy Lebeau

SafeSEH and CFG require compiler/linker support to setup additional data/code in the exe, so it's not enough to just enable their flags in the PE header. Delphi does not support SafeSEH or CFG at this time. But there is a SetProcessValidCallTargets() API you can call in your own code to implement CFG manually, at least.

I don't really have an answer for you. All I can think of right now is either 1) maybe you still have old files on your system somewhere, or 2) maybe you didn't recompile/separate everything when switching between release and debug builds.

REMOVE 'TfrmDatabaseTutorial.' from the DECLARATION! public { Public declarations } procedure ShowSelectResults; // <-- NO TfrmDatabaseTutorial here! end; It belongs only in the IMPLEMENTATION: procedure TfrmDatabaseTutorial.ShowSelectResults; // <-- ONLY here! var headline : TStringList; ... end;

Do you NEED to recompile the IPPeerAPI abstraction layer, though? Are you actually using any Embarcadero techs (DataSnap, etc) that are affected by updating the main Indy library?

Can't you just update the declaration of TPasswordEventPeer in IPPeerAPI.pas? FYI, at some point in a later version, Embarcadero changed TPasswordEventPeer again, to use TStringBuilder instead of String (why? I have no idea!).

If the '<...>' is always at end of the string then you could just SetLength() the string to truncate it, eg: Result := MyString; StartPos := Pos('<', Result); if StartPos > 0 then begin SetLength(Result, StartPos - 1); Result := TrimRight(Result); end;

No. Indy does not operate at the ethernet layer, so it has no need for MAC addresses. You will have to use platform-specific APIs, like GetAdaptersInfo()/GetAdaptersAddresses() on Windows, getifaddrs() on Posix, etc to get that kind of information directly from the OS.

Minor nitpick - you should pass in StartPos as a 3rd parameter to the 2nd Pos() call: Delete(Result, StartPos, Pos('>', Result, StartPos+1) - StartPos + 1) You might also want to Trim/Right() the Result after deleting the characters.

You would likely have to restore the original shipped copy of Indy when working with LivePreview and other affected projects. Embarcadero's shipped packages cannot be rebuilt, no. I recall at one point that the abstraction layer could be recompiled when updating Indy, but I don't have up-to-date details about how to do that in modern IDE versions.

This is not StackOverflow. We don't give out points here.

I'm not aware of any documentation that explains how detours work under x64. Please show your actual code that is creating the global hook and the detour. WHERE are you installing AND UNINSTALLING the hook and detour? What do your hook and detour actually look like?

Did you remove the hook before quitting Windows? Is your hook DLL accessing outside resources that may no longer be accessible during Windows shutdown? Again, why are you dealing with Detours at all? In any case, where exactly are you setting your hook/detour, and are you backing it out later when you don't need it aymore?

You can't detour code in an external process. You would have to inject your detouring code into every running process. Why not just use SetWindowsHookEx() instead to set a global WH_CALLWNDPROC hook?

You can't. If it's not on-screen, Windows doesn't physically render it. It makes no sense to send user input to an invisible window. Then why are you bothering with creating UI elements that will never be shown on-screen? No, FMX (or VCL) apps cannot be displayed inside a web browser. They don't work for good reason - there is nothing to capture.

I'm referring to any API that is provided by the OS which is specifically designed for comparing paths and/or filesystem objects. For example, PathIsPrefix() Also see: Best way to determine if two path reference to same file in Windows?

Just note that comparing filesystem paths as plain strings is not 100% reliable. Better to use system APIs that are better suited for that task, so you don't run into issues related to differences in casing, localization, 8.3 shortening, etc...

Then you should have said something earlier. I whipped up those examples off the top of my head, I didn't test them (and stated as much). What is the exact error message, and on which line(s) of code? Can you be more specific? What is your root folder? What is your selected folder? While walking the parent tree, which folder are you getting the error on (ie, what is the display data for the failing IShellItem)? You should have said something earlier. How else are you going to learn? That won't solve your main goal, since you will only be getting individual folder names from it, not full paths.

I literally gave you such code a week ago. Did you not see/try it?

How does that not work, exactly? Both Count() and Items[] take NativeInt now, you should not need the type-cast. That being said, why not use the Last() method instead? LastCol := Cols.Last.ColNumber + 1;

What's New: Delphi RTL and Data Improvements - Delphi RTL - List, Arrays, and Collections Improvements

Indy doesn't send an email differently based on server, so if Microsoft is not processing an email the same way that other servers are, then you probably need to contact Microsoft for support, and send them examples of emails that are not displaying correctly.

The 1st parameter of TRttiField.SetValue() expects a pointer to an object instance that the field belongs to, not a pointer to the field itself. Your function's Result is an array of T, is T an object type? If so, then you should constrain T with the 'class' constraint so that the compiler knows T is a class type, and thus Result is an array of object pointers. Can you provide a more complete example of what exactly you are trying to accomplish? Where are you getting the TRttiField from to begin with?

If it hasn't already started copying files onto your disk drive, ie because you didn't tell it where to install to yet, then I think you're fine.

Which post are you referring to? The code you have shown does not look like code I would have written. Note that the TFileOpenDialog.DefaultFolder applies only if there was no folder previously selected with the same dialog. You might want to prepare your initial IShellItem to your desired root folder before you open the dialog. That being said, you are setting the CanChange parameter to true only if the selected folder and the default folder are the same, which is not what you want. You need to check if the desired initial folder is a parent/ancestor of the selected folder. So, for that, you need to take the Dlg.ShellItem and walk its parent list comparing each one individually until you find a match or exhaust the list. Or, you could query each IShellItem for its ITEMIDLIST and use ILIsParent() or equivalent. For example (untested): var MyFolderShellItem: IShellItem; ... if Succeeded(SHCreateItemFromParsingName(PChar('C:\MyFolder'), nil, IShellItem, MyFolderShellItem)) then try FileOpenDialog1.Execute; finally MyFolderShellItem := nil; end; ... function IsParentOf(ARoot, AItem: IShellItem): Boolean; var iOrder: Integer; iParent: IShellItem; begin Result := (AItem.GetParent(iParent) = S_OK) and ((iParent.Compare(ARoot, SICHINT_ALLFIELDS or SICHINT_TEST_FILESYSPATH_IF_NOT_EQUAL, iOrder) = S_OK) or IsParentOf(ARoot, iParent)); end; { alternatively: function IsParentOf(ARoot, AItem: IShellItem): Boolean; var RootIdList, ItemIdList: PIDLIST_ABSOLUTE; begin Result := False; if SHGetIDListFromObject(ARoot, @RootIdList) = S_OK then try if SHGetIDListFromObject(AItem, @ItemIdList) = S_OK then try Result := ILIsParent(RootIdList, ItemIdList, FALSE); finally CoTaskMemFree(ItemIdList); end; finally CoTaskMemFree(RootIdList); end; end; } procedure TForm1.FileOpenDialog1FolderChanging(Sender: TObject; var CanChange: Boolean); begin CanChange := IsParentOf(MyFolderShellItem, (Sender as TFileOpenDialog).ShellItem); end;

Yes, your understanding is correct, but that wouldn't actually be a problem if each header handled its own alignment directives locally and made sure any alignment changes didn't bleed out into the caller's code.