Uwe Raabe

I actually thought of something in this direction before while I was hit by a case change in a unit name (.PAS became .pas) in combination with a poorly configured version control system (originally targeting - guess what - Linux). I will increase the priority now.

Was just going to write something similar. Most of the hassle when working with legacy projects are caused by these kind of classes.

Same here. I make use of TStringList way more often without any file involved than for text file processing. If I need some extension to the standard TStringList behavior I prefer to derive a special purpose class from it.

I usually close the project only , but I would indeed close the IDE if I had to exchange my design packages, which is another point to avoid them. (Sigh! Sometimes I miss the automatic branching in NNTP readers...)

Yes, but that is not causing the PITA I was talking about. When you switch one of these bpl files (even with vcs) it requires to unload the design time package from the IDE and load the changed one afterwards. In case these packages are part of the current project group it might as well be convenient to recompile those packages after the switch, which will do the unload-load internally.

Design time packages can be a PITA when you often switch source code versions affecting those components.

I have seen problems with shared folders in VMware when files are touched by the VM - somtimes they cannot be deleted from the hist until I restart the guest OS. I switched to local copies inside the VM and use the source control system to synchronize, so the problem is no longer existent. You might consider exposing the relevant folders as normal network shares and use these inside the VM instead of Shared Folders. This usually worked flawlessly for me.

Unfortunately that is not always sufficient. F.i. it is valid to require VCL, but that implicitly includes RTL. In addition, that only references the DCP files and not the actual BPL files, which names are not necessarily extended with a 270 or so.

Some things just need their time...

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>