Leaderboard

And that is why SRP goes down the drain, cyclomatic complexity increases, potential bugs increase, stuff gets broken - mostly in such swiss army knife classes. And what is complete - that differs for everyone.

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

This is the SO post: https://stackoverflow.com/questions/63823156/using-delphis-trichedit-is-there-a-way-to-set-up-a-link-so-someone-can-click I can comment Remy's answer in the dupe, which I am using to good effect: https://stackoverflow.com/a/42536393/505088

Hi, I see Embarcadero have released 10.4.1. I'm especially happy they are fixing problems found in prior versions, more so than any 'new' features. However, yet again they say you need a total uninstall and reinstall for this update. What I don't understand is why a full uninstall is necessary for a 'minor' release. This isn't 10 to 11, or even 10.4 to 10.5 - this is one level further - 10.4 to 10.4.1! A full install causes me all sorts of issues. I have a few add ons which I I have to wait on other companies to provide their own updates to the new version which can take weeks. Recall the problems with the Konopka VCL components when 10.4 arrived, it was a couple of weeks before they provided and updated set in GetIt and that component suite is owned by Embarcadero! Even Ray Konopka couldn't understand why this happened. Some companies must have many more add-ons than I have and suffer more than I do with this issue? Surely for a minor upgrade all that is needed is replacing the files that have changed, which can't be that many (being a minor upgrade)?

The most common way do text-processing in Delphi is to load a file into a TStringList and then process the text line-by-line. Often you need to save the contents of the StringList back to the file. The TStringList is one of the most widely used RTL classes. However there are a number of limitations discussed below: a) No easy way to preserve line breaks on Load/Save TStringList does not make any effort to recognize the type of line breaks (LF, CR or CRLF) in the files it opens, let alone save that for use on saving. b) Information loss without any warning or any option for dealing with that. Internally TStringList uses unicode strings, but when you save its contents to a file using the default encoding (ANSI), this may result in information loss, without getting any warning or having any means for dealing with that. TEncoding.GetBytes also suffers from that. c) No easy way to determine whether a file you loaded into a TStringList contained a BOM When you load a file (LoadFromFile method), the encoding of the file is stored but not the information about whether the file contained a BOM or not. The WriteBOM property is only used when you save a file. d) Last but not least, no easy way of dealing with utf8 encoded files without a BOM The default text file format in Linux systems, in Visual Studio Code and other editors, as well as in languages such as python 3 is utf8 without BOM. Reading such files with TStringList is problematic and can result in errors, because it thinks such files are ANSI encoded. You could change the DefaultEncoding to utf8, but then you get errors when you read ansi files. No effort is made to detect whether a file without a BOM contains utf8 sequences. Overall, it is desirable that, when you load a file using LoadFromFile and then you save it using SavetoFile, the saved copy is identical to the original. I am attaching a general purpose TStringList descendent that deals with all the above issues in case anyone has a use for that. XStringList.pas

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 splitted this thread off this

Topic splitting can easily done by mods. Personally I would welcome if this was done more often so different things can continue being discussed in their own threads.

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.

Just a small update, I managed to implement the resizing logic and it was really, really easy. Most of my time went away by drawing the transparent, themed, system default resize gripper... ...which almost can not be seen on dark styles, so totally with it! 👍 Frames above and below are adjusting properly, not changing places or jumping around. Overflow is handled correctly by the alClient scrollbox, if the contents grow too large for the window. The only thing is that I did not use splitters, I wrote the resizing logic myself (which is awfully long, like 10 lines of code?) Procedure TMultiLineParamFrame.ResizeHandleImageMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Begin _resizing := True; SetCapture(Self.Handle); End; Procedure TMultiLineParamFrame.ResizeHandleImageMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); var relative: TPoint; begin If Not _resizing Then Exit; relative := ScreenToClient(Mouse.CursorPos); If relative.Y > 47 Then Height := relative.Y; // Burned in magic number, because we all love them! End; Procedure TMultiLineParamFrame.ResizeHandleImageMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Begin ReleaseCapture; _resizing := False; End; Drawing the gripping handle: Constructor TMultiLineParamFrame.Create(AOwner: TComponent); Var bmp: TBitmap; Begin inherited; _resizing := False; bmp := TBitmap.Create; Try bmp.Height := 16; bmp.Width := 16; bmp.TransparentColor := clYellow; bmp.Canvas.Brush.Color := bmp.TransparentColor; bmp.Canvas.FillRect(Rect(0, 0, bmp.Width, bmp.Height)); StyleServices.DrawElement(bmp.Canvas.Handle, StyleServices.GetElementDetails(tsGripper), Rect(0, 0, bmp.Width, bmp.Height)); ResizeHandleImage.Picture.Assign(bmp); Finally FreeAndNil(bmp); End; End;

You just put them in a designtime package, install it, and then use them. That's what I do. I don't find it at all onerous.

Yes. No, it's no trouble at all.

I need to go back over this at the weekend (no time at the moment due to the day job) but I seem to remember one of the techniques I tried required a fully qualified name which I think we can build from enumerating the packages and their components in the IDE.

This is the command line parser we use in FinalBuilder and DUnitX and the package manager I'm working on. https://github.com/VSoftTechnologies/VSoft.CommandLineParser

That looks easy at first. You've found yourself there are limitations. But you forgot one important: using a TStringList load the full file into memory. This is probably not desirable if you want to support arbitrary large files. As previous answers mentioned, there are other possibilities. The best solution depends on what you intent to do. Sometimes it is easy to use memory mapped file.

Ok, then probably some incompatibility - please report if it ever occurs again with 1.1.9.0 If the fact that with some bad code in a plugin you can completely bring down the IDE is a "problem of the IDE" then I would say it is very likely. I think this has discussed before - especially as some plugins do quite some nasty things which can offer amazing functionality but are very very brittle - and in fact causes quite some work on the IDE devs as they cannot simply refactor or even rename stuff internally as they would like to.

The docking issue with TestInsight has been fixed in TestInsight 1.1.9.0. Kudos to @Stefan Glienke See:

This is a tradition and traditions are not to be messed with. No matter how annoying the are.

They might be following this thread already. 😉 Considering the fact that only the IDE has changed and that the same third pardy add-ons didn't cause exceptions in 10.4.0, it may also be the case that the add-ons uncover problems of the IDE.

Oh boy, Installed 10.4.1, TMS Components, GExperts and TestInsight, dragged a .groupproj onto the IDE to install more components and the IDE crashes completely. So much for a "quality" update 😞

Traditions should be ditched if they don't provide a happy client base 🙂 When I went to 10.4 from 10.3 none of my add-ons worked and needed re-installs. I've contacted my vendors and asked this question, still awaiting their reply. My feeling is they will need an update, even though this is a minor upgrade. I hope for otherwise. Yes, I'm installing on my other machine to see what's what.