Rollo62

Interesting question. Feasibility with Hooks: - Key Hooks (WH_KEYBOARD_LL): These are irrelevant for detecting paste operations, as pasting is typically triggered via mouse or context menu, not keyboard shortcuts. - Global Mouse Hooks: These can detect right-clicks but cannot reliably identify the "Paste" command or the target directory. - Shell Hooks (HSHELL_*): Using SetWindowsHookEx with WH_SHELL or registering for Shell notifications (SHChangeNotifyRegister) might provide some context about Explorer actions, but they do not directly expose paste events or destinations. Alternative Approaches: - Windows Shell Extensions: Create a Shell Extension (e.g., a context menu handler) to intercept paste commands in Explorer. This requires injecting code into Explorer’s process, which is complex and may have security implications. Maybe that could work for you, although it interferes too much with Windows systems for my taste.

Thats a fair move. Videos are not so easy to be changed https://youtu.be/77bQ6Xs0kBE?t=2598 So I hope that at least some core BLE improvements were still visible.

This depends a bit on what you really need to test in your app. If you want to test all kinds of dynamic hardware stuff a phone can do, then I would always recommend a real device. Only that can behave truly by accleration/motion/orientation sensors, touchscreen, phone calls, etc., the simulator can only roughly simulate that. If your app is mainly a "form" app with controls, not using a lot of specific hardware of the phone, then the simulator could be good enough for you. As far as I know, the debugging doesn't work under iOS simulator too, but still under Macos. So it is always a good idea to test under Windows/Macos first, and only then check the "view impression" and handling by iOS simulator or device.

Thats easy to solve, you just have to patent your prompts then

How can that happen, also I have seen this note about MTU in many "whats new" references from Embarcadero and looking forward to this. I'm not yet on 12.3, is this really missing in the source codes, or is it just defined for some platforms?

Thanks for sharing. You are still on Parallels Desktop 19, while there is already 20 out, is there a specific reason? https://kb.parallels.com/en/130212/ I'm quite sure that they have done a lot of performence improvements in this new version too, would be great see your direct comparison for this too in the future.

I also understand the urge to have such handy property, for convenience. On the other hand, if I consider the DataSource as part of the view and the Dataset as part of the model, perhaps there is a good reason to hide it here, so that the model doesn't know about its views.

Yes, I agreed to this already 10 thread posts before. I only asked if anybody already looked into it and/or tested against it. Any terms within the former sentence may start further massive nitpicking, I know. Nevermind, it's OK then for me.

Mindful misunderstanding of other peoples Intention and expressions is also a Form of Art.

Yes you are right. VCL/FMX unit linkage is comparable to DB and Windows-Service. Also tests for other platforms are completely superfluous, especially if Win32 ASM code is used in the library, nothing can go wrong here. I revoke all my silly notes above, they seem to be too stupid.

Excaclty, it should not ... Thats why I asked, if its tested against those and ensured that no hidden UI units are linked or involved. I think everyone can very well understand the meaning of my question here, even if VCL/FMX mentioned. There are too many VCL-only libraries out there. But thanks for your clarification.

Peeking into this nice library, it seems pretty much multi-platform compatible to me, even if there were some encapsuled Intel ASMs inside. Nevertheless, it seems to be specified only for x86 basically. Have you tested this under VCL, FMX, Win32, Win64, Macos (x86/ARM), iOS, Android, Linux as well? Would be great to know, if this is fully supported under all Delphi platforms, maybe it was already tested against these?

Flicker? Is that the case under VCL? Maybe this is interesting for setting per control https://blogs.embarcadero.com/vcl-per-control-styles-coming-in-rad-studio-10-4/

If indentation is your main focus, then I would suggest to port an large ERP system first into Python, keeping the indentation 99% valid, and then later port this from Python to Javascript and modern web technologies. This makes things much easier and I think this is the way DOGE is looking for.

You could use a setter for sQuery, that sets up the SQL before showing the form. That would not nee FormShow.