Remy Lebeau

Sure, but I shouldn't really have to go to that much trouble in the first place just to get basic behavior.

And RandomFrom()

RandomRange() has been around since Delphi 6.

Can you be a little more specific? What are the full error messages? Are you trying to use the version of Indy that ships preinstalled with the IDE (it should "just work" out of the box), or did you replace it with a newer version of Indy?

One option would be to create 4 lists and fill them with the possible numbers, and then generate a random index for each list, where you remove each found number from subsequent lists before generating indexes for them. For example: var values1, values2, values3, values4: TList<Integer>; value1, value2, value3, value4, index: Integer; procedure populate(list: TList<Integer>; startValue, endValue: Integer); var value: Integer; begin list.Capacity := endValue - startValue + 1; for value := startValue to endValue do list.Add(value); end; procedure checkAndRemove(list: TList<Integer>; startValue, endValue, valueToRemove: Integer); begin if (valueToRemove >= startValue) and (valueToRemove <= endValue) then list.Remove(valueToRemove); end; begin values1 := TList<Integer>.Create; values2 := TList<Integer>.Create; values3 := TList<Integer>.Create; values4 := TList<Integer>.Create; populate(values1, 1, 300); populate(values2, 100, 550); populate(values3, 250, 750); populate(values4, 500, 1000); index := random(values1.Count); value1 := values1[index]; checkAndRemove(values2, 100, 550, value1); checkAndRemove(values3, 250, 750, value1); checkAndRemove(values4, 500, 1000, value1); index := random(values2.Count); value2 := values2[index]; checkAndRemove(values3, 250, 750, value2); checkAndRemove(values4, 500, 1000, value2); index := random(values3.Count); value3 := values3[index]; checkAndRemove(values4, 500, 1000, value3); index := random(values4.Count); value4 := values4[index]; values1.Free; values2.Free; values3.Free; values4.Free; end;

Perhaps run $(BDS)\bin\LicenseManager.exe and remove your beta license if it's still listed?

Agreed! Something that is really annoying me since installing 12.0 is when I double-click on a .pas/.cpp file outside of the IDE, and the IDE is not running yet, the IDE is started, but it wastes time loading all of its default packages and layouts, and then opens the .pas/.cpp file, and then finally goes to the Welcome screen instead of the .pas/.cpp file. Loading the packages, the Structure view, the Palette, etc is all completely unnecessary and the Welcome screen is completely unwelcomed when I just want to view a file. I expect the IDE to basically just present me with the code editor and nothing else. If I want the full IDE experience, I'll open the full IDE myself, or at least open/create a project and expect the IDE to (re)load everything it needs to support that task.

Better to use CompilerVersion (and RTLVersion) instead, then you don't need to update the defines every time a new version is released, only when you need to add a new define, eg: {$IF DEFINED(DCC) OR (CompilerVersion < 23)} {$DEFINE EC_DELPHI} {$IFEND} {$IF CompilerVersion >= 20} // Delphi 2009 {$DEFINE EC_UNICODE} {$IFEND} {$IF CompilerVersion >= 34} // Delphi 10.4 {$IF CompilerVersion < 35} {$DEFINE EC_VCL27} {$IFEND} {$DEFINE EC_VCL27_UP} {$IFEND} {$IF CompilerVersion >= 36} // Delphi 12 ... {$IFEND}

Then you are likely doing too much work in your drawing code. Or you are doing other things besides just drawing. Painting should be a quick task. Draw only what can be seen for the current state of your existing data, nothing more. Do not manage your data/UI in any way other than drawing. If you need to manipulate your data/UI, that has to be done outside of a paint cycle. That is not how UI painting works. You have to draw whatever your current state represents. After the painting is finished, if a state change occurs, then you can trigger a repaint to draw the updated state. No. Every paint cycle is a complete redraw from scratch. For each window/control that is being painted, you have to draw it entirely in a single cycle. And then again in the next cycle. And so on. You can Invalidate() an individual form/control to trigger a new paint cycle for it, but that requires you to redraw it entirely from scratch when that next cycle begins,

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...