Leaderboard

Ctrl + Alt + F12 starts the Intel graphics settings for me But the far right in row, there is a down arrow to display the entire list.

Not sure if it fits your needs, but nevertheless this might be an interesting read for you (unless you have already done so): Dataset Enumerator Reloaded And here ist the corresponding rep: DataSetEnumerator

Great plugin @santiago! Small Suggestion: Show/identify which units have been changed, like IDE does: Maybe something like this:

@Dinar :)) Sorry, looks like I'm in write only mode 🙂

This is one of the first options I proposed 🙂

@Lars Fosdal Ok, ok, I just wanted to expand the topic: FireDAC, RTTI and generics 😉

Look at my idea, without records, but with interfaces, SQL is generated automatically, moreover UPDATE and INSERT works 😉 https://github.com/jaclas/transfORM

O R M

You package must be flagged as "Design time page". See the package project options.

This was all covered in

Component -> Install Component Browse to file name, and select Install into a new package.

Yes, exactly. UCS4String predates Delphi 2009, it was first introduced in Delphi 6 alongside UTF8String, which at the time was just an alias for AnsiString. In Delphi 2009, when AnsiString became codepage-aware and UTF8String became a true UTF-8 string type, UCS4String did not become a true UCS-4 string type, it remained a plain dynamic array. Since the D2009+ version of the StrRec record supports characters of varying byte sizes, I've asked for UCS4String to be changed into a true string type using 4-byte chars, backed by the same RTL logic that handles AnsiString(N) and UnicodeString, but that never happened.

Looking into it. I have the impression the original design assumes a UCS4String to have a null terminator. s:= [98,101,114,109,228,223,105,103,0]; // "übermäßig" Not only If you add 0 to the array everything works, but if you call UnicodeStringToUCS4String this is exactly what you get (an array plus the #0) s:= UnicodeStringToUCS4String('übermäßig'); //[98,101,114,109,228,223,105,103,0]; // "übermäßig" ShowMessage (length(s).ToString); Honestly, I don't see us putting a lot of effort in UCS4String

I think you can remove this keyboard shortcut or reassign to something else in the Intel Graphics settings (unless, of course, you do not use it that often) 🙂

Have you tried using keyboard shortcuts to display a dropdown menu with a list of all open modules (Ctrl + Alt + F12) or the DelphiCtrlTab plugin?

I think you might be confusing UTF-8 and Unicode because your example is using unicode strings and not UTF-8 strings. If what you have is in fact unicode and you just want to remove non-printable characters then you can use the TCharacter class: for var i := Length(s)-1 downto 1 do if (not TCharacter.IsValid(s[i])) or (TCharacter.IsControl(s[i])) then Delete(s, i, 1);

Major rule of optimization says: Benchmark First Before Trying To Optimize 😉 . Syntax sugar is created for code simplicity and shortness and in most cases perf degradation will be insignificant I've really seen perf gain in string processing. With index loop you have ArrPtr + I*SizeOf(Item) each time which could, f.ex., cause cache misses. OTOH, Inc(CurrPtr, SizeOf(Item)) always operates on near memory area. Honestly I'm not a CPU-level expert and array loops could be well optimized already but in my case benches shown that pointer loop is faster.

The two 0b characters are valid UTF-8 characters. They are this character: https://www.fileformat.info/info/unicode/char/000b/index.htm What you need to do is decide exactly what your specification is. The question you have asked doesn't seem to match the example you have provided.

I forgot another extremely important thing. I never commit everything blindly, I always check every change before commiting to avoid accidental errors and changes in files that should not have been changed.

Actually, I like this and make heavy use of it. begin if Value.StartsWith(Prefix, IgnoreCase) then Result := Value.Substring(Prefix.Length) else Result := Value; end; is just easier to read than var isPrefixed: Boolean; begin if IgnoreCase then isPrefixed := StartsText(Prefix, Value) else isPrefixed := StartsStr(Prefix, Value); if isPrefixed then Result := Copy(Value, Length(Prefix) + 1, Length(Value)) else Result := Value; end;

Maybe "git diff" and "git blame" would show something useful. You are a team of developers and go with "something is messed up" statements? Usually this come from the clients.

Why would there be conflicts in files that you have not modified? My advice to you is that before you try to change the process to fix the problem, you make sure that you have fully diagnosed the problem.

I've been using Git for a few weeks only, so I could be way off base here... but doesn't every conflict have details on who changed what that conflict occurred in the specific file? Is it your username for all the changes?

If you are not working in A, B and C then you simply should never see any conflicts. My guess is that someone in your organisation is using git incorrectly. No reason at all that you should have any troubles with all this in a single repo.

850 repos for every client specific variation sounds kinda crazy. I suspect that you aren't getting great feedback here because your organisation's work flow is, er, unique.