Leaderboard

We have open sourced our Deployment Manager to simplify deployment of a large number of files or folders to iOS or Android. https://blog.grijjy.com/2021/02/07/deployman/

Don't use the IDE managed version resource. Use an external RC file with a version resource instead and update it with whatever suits your build pipeline best. For example a simple bat or cmd file. I'm sure there are lots of homegrown utilities that can update the version in the dproj, an RC or RES file but I like to keep the number of dependencies down. A utility would just be yet another piece of software to install, maintain, etc.

Actually there was a time (in the 1990ies) when we did exactly that: Recompile the whole VCL/RTL in our projects. Mostly because we had to fix some bugs. These bugs were fixed by Borland (Yes, there was a time where this happened quickly.), so we stopped doing that. It also became impossible to simply recompile the RTL because it required some assembler. As for components: Yes, I still compile them from sources in programs that do not use packages. I want to be sure that the source code I see while debugging is the actual source code used in the program. Given Delphi's compile speed it doesn't really matter much. But we degrees. Of course every program has its own dcu output path. Sharing that between multiple programs is a really bad idea.

Delphi 1

At least since Delphi 7 (cannot check versions below in the moment). Just have a look at DB.pas (out of many others): function TFieldDefs.GetFieldDef(Index: Integer): TFieldDef; begin Result := TFieldDef(inherited Items[Index]); end; or the ancient Contnrs.pas: function TObjectList.GetItem(Index: Integer): TObject; begin Result := inherited Items[Index]; end;

We use Continua CI + FinalBuilder to manage versions.

I'm not sure what you are referring to there, but I was referring to the statements that: It's wrong to have the TMyButton class and the Register produce in the same unit. You need to have both a design- and a run-time package. This requirement is documented. Yes. I'm sure. In one of the many discussions I've had with Remy on this topic I checked the documentation all the way back to Delphi 1 and nowhere does it state that one must (or should) have both a design-time and a run-time package. I have also failed to find any other authoritative sources for the claim. It's always something that people heard from a friend of their 2nd cousins yoga teacher - or something like that 🙂 My claim is that, unless you link with run-time packages or share code between design-time packages, it's perfectly acceptable to put everything into a design-time package if you can. I.e. you don't need the run-time package. This also makes creating and maintaining design-time packages so much easier.

No it still doesn't work, and I realize I forgot to create an issue about it. Now it is there: https://quality.embarcadero.com/browse/RSP-32362

Bad idea IMO. Sharing DCUs among projects only leads to problems in my experience. When I do a clean build I want everything built from scratch, with the options I have enabled at that time. I don't want the compiler to link in some old DCUs that were compiled with god knows what options. You don't need to (as I explained) but it's cleaner design to separate design-time code from run-time code.

MadExcept has an option to compile with memory overrun/underrun checks enabled. It makes heap allocation really slow and add a lot of overhead but it's good if you suspect a memory overwrite and have no clue about where the problem originates. I don't know if Eurekalog has something similar.

Yes it's normal that it compiles. RegisterComponents is a regular function located in the classes unit and if you couldn't use classes.pas from a run-time package then you couldn't do much at all. You don't necessarily need to have both a run- and design-time package (yes, there are different opinions on that) but if you have decided to split the packages into run- and design-time then I guess you should move the RegisterComponents into separate registration units and place those in the design time package.

http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Stan.Option.TFDFormatOptions.InlineDataSize

From 18 GB RAM, 0,5 GB is dedicated to RAM disk, so this is negligible... I prefer to write .dcus there, so that it does not write again and again to SSD, it is faster and .dcus are always fresh.

function StrSize(const Str: UnicodeString): Int64; inline; begin Result := Length(Str)*SizeOf(WideChar); end; function StrSize(const Str: RawByteString): Int64; inline; begin Result := Length(Str)*SizeOf(AnsiChar); end; function StrIsStartingFrom(const Str, SubStr: string): Boolean; begin Result := False; if ((Str = '') or (SubStr = '')) or (Length(SubStr) > Length(Str)) then Exit; Result := CompareMem(Pointer(Str), Pointer(SubStr), StrSize(SubStr)); end; function StrIsStartingFrom(const Str, SubStr: RawByteString): Boolean; begin Result := False; if ((Str = '') or (SubStr = '')) or (Length(SubStr) > Length(Str)) then Exit; Result := CompareMem(Pointer(Str), Pointer(SubStr), StrSize(SubStr)); end; ADD: If you just check 1st char of a string, then simple `if Str[1] = SomeChar` will be faster; moreover it could be optimized further as `if Pointer(Str)^ = SomeChar` but you'll have to ensure Str is not empty

(**bolding in the quote is mine -- John) The term "reference" comes to mind. You want to compare brightness level of the screen - as you see it - to the overall brightness level of the room. You then want to adjust screen brightness to a value that suits your personal comfort level. Essentially, *you* (your internal values) are the reference for this comparison. *You* are the perceiver of the room and screen brightness levels. So, these values are external to the computer. As noted above, you also provide the reference value for comparison. Meaning the reference value is also external to the computer. Somehow, you have to get these 3 values into the computer (your software) in order for it to make appropriate screen adjustments. If you want this to be an automated process, then ideally you will need to have room and screen brightness sensors sending data to the computer (your software). You will also need to quantify the reference value (remove it from the subjective) for comparing room and screen brightness. In the not-so-ideal world, maybe you can fudge a number for room brightness and do an internal calculation of screen brightness. Perhaps a reference value could be arrived at by trial-and-error. All this would remove the need for external hardware. Make sense...? John

There is a page in the Delphi wiki on creating packages. https://delphi.fandom.com/wiki/Creating_Packages Edit: I had totally forgotten that I wrote that page myself (many years ago). After reading through it, I must say I still like it. There isn't much I'd change today.

In photo editors you usually have a histogram function which gives a distribution of the brightnes levels as a curve. With that you could find out whether more of the image is dark or bright. Most such photo editors can calculate this really quicky. So histogram might be a keyword to look for.

But we are not StackOverlfow. Thank god. I''ve got some code for calculating brightness, but this is for converting color bitmaps to grayscale. I'm not sure whether this fits your purpose because perceived brightness of a screen might be different of the brightness of a picture. type TRgbBrightnessChannelEnum = (rcbAverage, rcbFastLuminance, rcbRed, rcbGreen, rcbBlue, rcbLuminance); function GetFastLuminance(_Red, _Green, _Blue: Byte): Byte; begin Result := Round(0.299 * _Red + 0.587 * _Green + 0.114 * _Blue); end; function GetRgbLuminance(_Red, _Green, _Blue: Byte): Byte; var Hls: THlsRec; begin GetRgbHls(_Red, _Green, _Blue, Hls); {$IFDEF dzUseGraphics32} Result := Round(Hls.Luminance * HLSMAX); {$ELSE} Result := Hls.Luminance; {$ENDIF} end; function GetRgbBrightness(_Red, _Green, _Blue: Byte; _Channel: TRgbBrightnessChannelEnum): Byte; begin case _Channel of rcbAverage: Result := Round((_Red + _Green + _Blue) / 3); rcbFastLuminance: Result := GetFastLuminance(_Red, _Green, _Blue); rcbRed: Result := _Red; rcbGreen: Result := _Green; rcbBlue: Result := _Blue; else // rcbLuminance: ; {$IFDEF dzUseGraphics32} Result := Round(GetRgbLuminance(_Red, _Green, _Blue) * HLSMAX); {$ELSE} Result := GetRgbLuminance(_Red, _Green, _Blue); {$ENDIF} end; end; This is from the unit u_dzGraphicsUtils from my dzlib.

If you haven't already, try using a different cable

Please stop to wonder about the font(s). It does not matter! The problem is the text rendering itself in the editor of the Delphi IDE. In the screenshot you can see a few examples in the Delphi IDE and in Visual Studio Code. In both cases, the font is the famous Consolas from Microsoft (https://en.wikipedia.org/wiki/Consolas). Most european languages like German, Swedish or Hungarian are well rendered. Even Greek is displayed nice. But all others looks like a pile of shit. Arabic is broken, Thai has to much space between the symbols. The same problem occours in Khmer and Sinhala (mispelled as Shinghal in the source code). Chinese look okay, but not perfect. Conclusion: The Delphi IDE Editor is designed for European character sets only.