Leaderboard

Premature optimisation

Look for more traffic here soon as they are discontinuing their public forums. (Their current forums are horrid to use...maybe they should replace the forum software instead...) https://blogs.embarcadero.com/august-2020-gm-blog/

I know DDevExtensions has it with a double-click by adding a hidden registry key..

Apart from making the tabs inside the palette, it could also be an approach to have one or two new tool windows with the desired behavior. This would allow to dock these windows into a tabbed dock, achieving nearly the same as you describe, or set up an individual docking layout with the palette and the new window(s) being visible side by side. This could as well be realized by a 3rd-party IDE plugin bringing this functionality even to existing Delphi versions.

I use the same approach as @FPiette

Ow. Sir, with all the respect, that was too pathetic. I wasn't trying to convince you to change your workflow. There's a conversation on the thread's subject, right? So, just like you, I was just telling my experience.

If $I has a path (including relative), it is used based from the file containing $I directive. If $I has no path, default Search paths are used.

Allocating 4KB more for huge blocks is not an issue. If you want the buffer aligned with system page granularity, then it is a very specific case, only needed by other OS calls, like changing the memory protection flags. It is theoritically possible, but very rare. This is the only reason when using the internal MM is not to be used. If you expect to see any performance benefit of using memory page-aligned, you are pretty wrong for huge blocks - it doesn't change anything in practice. The only way to increase performance with huge block of memory is by using non-volatile/non-temporal asm opcodes (movnti e.g.), which won't populate the CPU cache. But this is only possible with raw asm, not Delphi code, and will clearly be MM independent.

I never use IDE global path, nor library folder. All my project have explicit paths (always relative) to everything, except components delivered with Delphi. All my components and all 3rd party components I use are all explicitly added to all projects they are used in. And I always recompile everything, never use a prebuilt dcu, obj or package. This way I'm always sure to have everything required to build an application. On the computer I use, it takes only a few seconds to compile hundreds of thousands code line. I use Delphi since version 1 (25 years ago) for almost full time. I wrote hundreds of applications, some of which are very large. I have always had great success. I will not change the way I work.

Famous last words. I hear the NSA is very fond of hardware firewalls. The firmware is often very old.

Do you mean you had your Windows computer directly connected to the internet and RDP activated? In my eyes that's disaster waiting to happen. There apparently is a big market for RDP addressee and accounts and they are even cheap (Heise online had an article on that today (in. German).)

In this example, no, since the only design-time functionality being used is RegisterComponents() which is implemented in the RTL in a runtime package, not a design-time package. So this example can exist in a single runtime+designtime package. Yes, so that the IDE knows that it is allowed to use this package for both installation into the IDE and compiling into executables. Yes, because designtime-only packages are not allowed to be compiled into executables, only runtime-only and runtime+designtime packages. Marking the package for runtime usage is important. Maybe not a hard requirement, especially in the early days, but around D6 or so this actually did start getting enforced. And besides, it is how the system has always been intended to be used, and how it gets documented by 3rd party books and such. And frankly, it just makes sense to do it this way. Component logic goes in a runtime package, design-time editors go in a design-time package. If there are no editors, the two packages can be merged into one. Simple and straight forward. Whether or not it works to compile a designtime-only package into a runtime executable is another matter. It is not supposed to work.

If you make the layered window be a child of the panel, then that will only work on Windows 8+. On earlier Windows, you would have to make the layered window be a top-level overlay window that follows the panel onscreen.

If the component does not have extra design-time functionality that directly interacts with IDE APIs (property/component editors, OpenTools plugin, etc), then you do not need to make a separate design-time package. You can create 1 package and mark it as being BOTH a runtime package AND a design-time package. That will work just fine.

MMX has two displays for cycles: a treeview and a Dependency Structure Matrix: