Uwe Raabe

I made a similar (simple) ring buffer implementation a couple of years ago, which worked well for my needs then, but I refused to publish it due to exactly these issues. Sometimes it is safer to re-implement things for some specific purpose by coding from first principles than use a pre-built all-purpose library implementation, that is neither easy to understand nor easy to debug. I know this is breaking the DIY rule, but it follows the KISS rule.

https://delphi.fandom.com/wiki/Bold_for_Delphi http://boldfordelphi.blogspot.com/2017/01/help-me-to-make-bold-open-source-project.html

Yes, it looks like some sort of CodeRage like online event. Despite more information I did register and got by email a payment receipt over $0.00 a confirmation "You're in!" a schedule listing three sessions The whole thing heavily lacks information. You simply don't know what you do if you register. Only the fact that no one asked for my credit card made me continue.

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.

How would this be supposed to work when you have two forms open each belonging to another project having conflicting design-time packages? We should also not forget that form, frame or datamodule instances are sometimes opened implicitly inside the IDE. I tried to get this straight with my Package Magician, but that still can handle simple cases only. A big blocker are package developers not caring about their packages being loaded and unloaded dynamically.

Var sl: TStringList; begin sl := TStringList.Create; TTask.Run( Procedure Begin Sleep(10000); sl.Add('added in Task thread'); TThread.Queue(nil, Procedure begin { this runs in the MainThread } sl.Free; end; End); end;

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

The Uses Report from Pascal Analyzer (Peganza) is pretty close to your needs. Perhaps even the free Pascal Analyzer Lite version will do here. Regarding other analyzers I can speak for Understand, which gives much more information but for a higher cost. About the same is true for Lattix Architect, for which MMX can produce the necessary output. I make use of all three tools quite often.

This question implies that it is shown on purpose. Most likely it is not.

Known issue: Invoking IDE Insight using Ctrl + . shows gray box over input field

Oh, I meant to have heard that they are trying to eliminate the dependence on DotNet 🤔

I guess, it is more likely taken from .NET: system.threading.monitor

In contrast to software a roadmap is always released when its ready.

Basically it is working! It is just that sometimes the Structure View context menu (or the actions behind it) seems not to be properly updated. After opening the context menu from the IDE Designer, the Structure View context menu is working again. Qualifies for a QP entry I think.

That would only work if you have the same packages installed as Carlos has.

<OT>Some say: MOIN is enough, MOIN MOIN is just chattering. (MOIN is' genug. MOIN MOIN is' schon Gesabbel)</OT>

Are you sure you are looking at the registry part of the user starting Delphi? You can also search the registry for the value shown in the error dialog. BTW, could it be that you installed MMX for All users instead of the recommended current one?

I can assure you they did! (BTW, most of the beta testing is done in Virtual Machines) Even I did and I have had no issues as described above nor do I have those now.

Just remove the corresponding entry from the registry in HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Experts.

Just curious: Why you would need that check in the first place?

In the moment I am able to track it down to Delphi 7, but I am pretty confident that it exists since Delphi 1.

You already can do that: {$IF Declared(TCustomAttribute)}

Perhaps I didn't explain it well enough. In case my code contains a check like: {$IF CompilerVersion < RAD_Chicago} {$IFEND} {$IF CompilerVersion < RAD_Sydney} {$IFEND} {$IF CompilerVersion < RAD_Rio} {$IFEND} that may perfectly compile with a future Delphi version named Chicago incorporating constants RAD_Chicago = 63; // no offence ... RAD_Sydney = 34; RAD_Rio = 33; ... but fails with any compiler available today. So I still need this one file with all these declarations and independent from the compiler. Where would be the benefit of Delphi providing a bunch of different versions of such a file where most of them are probably outdated and thus useless? Imagine we have each Delphi version in a separate VM, where almost all of these don't have the latest version of this file. Getting all this working will result in way more hassle than having this file maintained in one place, copying that into each project that makes use of it and keeping it up to date with each new Delphi version.

So it works with the small example, but fails in your main app? In that case there is something in your code you didn't show us. BTW, you indeed create a Form2 with Form1 as its owner, but as soon as you destroy Form2 it removes itself from Form1. So that is most likely not causing the problem. Just to make sure: In your example you name both forms MyForm. I hope that are different variables?

I try to write code that puts the lower Delphi versions under conditions. These are easier to eliminate when support for those older versions is dropped. Therefore you find constructs like {$IF CompilerVersion < 32.0 Tokyo } in my code, or sometimes even if CompilerVersion < 32.0 { Tokyo } then to avoid conditional compilation completely. Perhaps I am too lazy to update these include files in dozens of projects each time a new Delphi version arrives.