Leaderboard

32 bit processes on Windows aren't going away anytime soon. It's actually not hard to change the runtime to address these issues, which can effectively be summarised as isolating threads from each other's execution contexts. I would imagine that Emba don't do it because they perceive that the benefit is too small in comparison with other candidate developments. And remember that I'm proposing a breaking change in behaviour which always raises the bar. Personally I feel that it's important to build on solid foundations. We've just had a huge breaking change by the killing of ARC. So breaking changes can happen. And by the token that a minority of users care about floating point, breaking changes in this area won't affect many people. And surely those that are affected would by and large appreciate the change.

Hi, DDetours v2.2 is released. version 2.2(Jun 9, 2020): +Added support for older Delphi version: Now the minimal supported Delphi version is D7. +Added support for FPC. +Added recursive section feature: EnterRecursiveSection/ExitRecursiveSection. +Added param/tag feature for all InterceptCreate functions. +Added GetTrampolineParam function to get user param. +Added GetCreatorThreadIdFromTrampoline function to get thread id that created the hook/trampoline. +Added detection for non valid trampoline pointer. +Added unittest. +Replaced BeginHooks/BeginUnHooks by BeginTransaction. +Replaced EndHooks/EndUnHooks by EndTransaction. +Replaced GetNHook by GetHookCount. +Replaced TDetours<T> by TIntercept<T,U>/TIntercept<T> +Fixed many bugs related to MultiBytesNop. +Fixed wrong displacement value for some branch instructions on x64. +Fixed wrong offset size on x86 for GetJmpType function. +Removed v1 compatibility. +Now the library does not rely on Object. +Code refactoring. https://github.com/MahdiSafsafi/DDetours Some of the above features were planed for v3 that I started working on years ago. But I never get a chance to finish it. What a pity I'm rolling v2.2 instead of v3.2.

Don't mess with youself too much, if Microsoft shows not any attempt to make these controls practically more usable since the last 20+ years, why should we do ? I must really say that meanwhile I hate to fix all the quirks in OS, IDE, tools, libraries, etc. Enough to do with my own, selfmade errors

I don't think so. It's very important that code behaves the same way for both 32 and 64 bit compilers and indeed for the non Windows platforms too.

No insult taken. My attention may have slipped - I did not see the static part and for that I apologize. For the record, my intention was not to argue: I just had to refactor too many lines of code (written 10-15 years ago) which broke or misbehaved on specific modern systems. The days-weeks wasted there taught me to proudly waste hours when I write fresh code which will still work the same way everywhere in the foreseeable future. Do I still have "hacks" like this in production? Hell yes, I do. Do I hate myself for it when I see it? That's a question for a different topic 🙂

Use Weak<T> from Spring4D in any version before one that supports [weak] if you want proper cleanup of such weak references. Using the pointer approach will not do and you might run into AVs caused by dangling references.

Definitely not intentional. Will have a look. Thx for reporting. 🙂

In my opinion, just because there's a possibility to do something doesn't mean you should use it 🙂 I do understand and agree with you on this. But it's not for the others, it's because of my own self. I just don't want to produce code I don't like or as "time-resistant" as I can think of. Whilst it's a good thing it's a curse as well... I can easily waste hours on a single "Hello World" application this way.

Hi... ...you programming a own MessageDialog. TOwnMessageDialog = class strict private // own formular class function ShowMessage(MessageCaption: string; MsgType: TMsgDlgType; Buttons: TMsgDlgButtons; MessageLines: TStrings; Help: LongInt = 0; MessageColor: Integer = clBlack; Parent: TForm = nil): Integer; public constructor Create; destructor Destroy; override; class function MessageDlg(MessageText: string; MsgType: TMsgDlgType; Buttons: TMsgDlgButtons; Help: LongInt = 0; MessageColor: Integer = clBlack; Parent: TForm = nil): Integer; overload; // wie MessageDialog Original class function MessageDlg(MessageText: string; MessageHeader: string; MsgType: TMsgDlgType; Buttons: TMsgDlgButtons; MessageColor: Integer = clBlack; Parent: TForm = nil): Integer; overload; class function MessageDlg(MessageLines: TStrings; MessageHeader: string; MsgType: TMsgDlgType; Buttons: TMsgDlgButtons; MessageColor: Integer = clBlack; Parent: TForm = nil): Integer; overload; class function MessageDlg(E: EDatabaseError; MessageHeader: string; MsgType: TMsgDlgType; Buttons: TMsgDlgButtons; MessageColor: Integer = clBlack; Parent: TForm = nil): Integer; overload; end; Advantages: 1. own formular with corporate design 2. Parent for the message 3. own high (Count of MessageLines) 4. own with (longest text in MessageLines) 5. own Colors (Text) 6. scalable...dialog with every controls you want (inheritance) ...and so on.

You're like Superman.. faster than a speeding bullet 🙂 Thanks. Perfect!

Issue resolved. The cause of my problem is this: Myxcode-select command-line tool was not pointing to my main Xcode installation folder. This must have happened when I used brew to download the latest Xcode command line tools, and brew then set xcode-selectto point to a different path (/Library/Developer/CommandLineTools). I repaired this by issuing this command at the terminal, following the instruction from http://docwiki.embarcadero.com/RADStudio/Sydney/en/SDK_Manager#Troubleshooting_.28macOS_and_iOS.29 sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

Bug has been fixed :-). Have not recompiled the binaries yet.

I have pushed the changes to GitHub. Have not recompiled the binaries yet though, as I plan to do some more work on it. Unfortunately the Welcome Page behaves very differently than all other module types (*.pas, *.dfm, *.dpr, *.dpk, etc...). It does not trigger ViewActivated events. At the end I got it to work by using the INTAEditServicesNotifier.DockFormUpdated. This is the only method that is triggered whenever the Welcome Page is activated.

I might not phrased myself correctly - forgive me; English is not my native language. The point is, you know exactly what I meant by "distancing". Let's play adults and not starting to argue on choice of words.

of course does it work, just set the font size to 2. what is your problem?

What happened to that document? https://web.archive.org/web/20171221023547/http://qc.embarcadero.com/wc/qcmain.aspx?d=107411 Edit: I took the liberty of splitting David's answer into a new thread.