Uwe Raabe

Which platforms are in your project? There is indeed a different behavior for Windows-only projects and others. If there are other platforms than Win32 and Win64, the base configuration stays as is (usually it then is empty anyway). But perhaps something is just going wrong there.

I agree about Contains missing a case-insensitive option. On the other hand, the requested LowerCase functionality is already there under the name ToLower. Alas, there are more functions missing from the string helper where you need to fall back to the global ones.

But that applies to the Community Edition as well. The only way to get around it is to buy a commercial license then (which is what I do btw.)

Yes, read-only files are out of bounds. The latest version also recovers from any write errors caused by insufficient access rights.

AFAIK, Embarcadero offered a free one-year license (similar to what MVPs and Tech Partners get) to Andreas - probably more than once. Seems there is not much interest.

Actually I am thinking about some mechanisms for a DO NOT TOUCH! feature in Project Magician. While this is supposed to handle more cases than some Delphi library files only, I am still unsure how to implement it in a flexible as well as easy to handle way. I guess, this qualifies for a QP report anyway. Some sort of Clean Linefeeds action before commit/check-in should be mandatory - even for Embarcadero. Not to mention a Format Sources.

If a mutex is not working you are probably doing something wrong.

TRestRequest has also a method ExecuteAsync with handlers for successful completion and error handling (in addition to the event handlers OnAfterExecute and OnHTTPProtocolError). Depending on your specific needs it may boil down to just a simple call like this: RequestLogin.ExecuteAsync( procedure begin ShowMessage('server up'); end, True, True, procedure begin ShowMessage('server down'); end);

As all fields in that record are either 32 or 64 bit (depending on the target platform) it doesn't matter if the record were declared as packed or not.

Perhaps a simple "Open as text" in the context menu of a DFM in the project manager may be sufficient.

Which control is supposed to handle that key stroke? TDBGrid reacts on <F2> and <Insert>.

I have to find out...

If I got that right, Stefan is referring to the case where the array is relocated, which invalidates the record pointers. This is not the case for a class list, where only pointers to the class instances are stored inside the array. Relocating such an array will keep the instance pointers intact.

Isn't that just the same with classes? Of course one has to know what can be done and what should be avoided. That is no difference to the standard generic record list, where you need to know that you are changing content of copies of records and not that of the records itself. My approach (which may be more a proof of concept than a solution for production) allows to work with a generic record list just like with the standard one, with the feature to change the record contents in the list, just like it was a simple array of records. I am pretty sure that it will work for the majority of use cases. Whenever the language gets a new feature that makes this obsolete - so then. It is near to impossible (and probably not even desirable) to make everything fool proof. IMHO fools shouldn't be allowed to write programs in the first place.

I think that would be too much of a hassle, especially when you are working with relative paths and/or want to configure that on a per project/-group level. One could even throw wildcards in there to complicate things further. You can either switch off that feature or make the offending files read-only. BTW, I also get these LF problems with Spring4D all over the place, but I usually don't debug it. Interestingly, up to now it seems to be the only library with this hickup.

It is not very difficult to make a generic list for records that allows manipulating the record content directly: type TChangeableRecordList<T: record> = class(TList<T>) type PT = ^T; private function GetItem(Index: Integer): PT; procedure SetItem(Index: Integer; const Value: PT); public property Items[Index: Integer]: PT read GetItem write SetItem; default; end; implementation function TChangeableRecordList<T>.GetItem(Index: Integer): PT; begin Result := Addr(PList^[Index]); end; procedure TChangeableRecordList<T>.SetItem(Index: Integer; const Value: PT); begin inherited Items[Index] := Value^; end; A suitable test case could look like this: type TMyRec = record IntValue: Integer; end; var list: TChangeableRecordList<TMyRec>; myRec: TMyRec; begin list := TChangeableRecordList<TMyRec>.Create; try myRec.IntValue := 1; list.Add(myRec); Assert(list[0].IntValue = 1); list[0].IntValue := 3; Assert(list[0].IntValue = 3); finally list.Free; end; end;

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...