Leaderboard

Almost all syntax sugar is expensive. for-in means creating iterator, calling its methods etc instead of plain index addressing. But in most cases it doesn't matter. Anyway if speed is important, pointer-based iteration probably will be faster

You should examine the diff of your changes before you commit them instead of just committing all files that has changed. Practices differ but for example when I have made a change to a form I only commit that specific change - and directly derived changes. All the Explicit* and Original* fluff that the IDE changes are left out. Also adding a file to a project usually result in 40-50 changes (relating to platforms I haven't even installed) of which only one or two need to be committed.

That means going through diff list and making sure that all changes are expected changes - changes I intended to make (that does not mean I am rereading every line of code). For instance, first step is making sure that only files that had to change are changed - for instance if I am making changes in for code and I am not touching design and dfm (fmx) file pops in changed files, I will not commit those files and will revert changes after quick inspection. Next I will go through changes I expect and I did make. If I was working on class xyz and something is also changed in abc, well that means something is wrong. Such things don't happen often, but sometimes you mess things up during debugging or leave unwanted artifacts. I don't commit every two lines of code, but logical tasks. If the task is larger, then it can be spread through several commits.

Development of SynEdit at PyScripter has been moved to and merged with TurboPack SynEdit. The focus of the development is to modernize the code base and enhance the functionality (sometimes at the expense of backward compatibility). In addition to the earlier enhancements and fixes two more features have been recently added: Per-monitor DPI awareness Support for Font Ligatures (new option eoShowLigatures) Fonts like Cascadia Code and Fira Code contain ligatures relevant to programming. See this article for details. Are you using font ligatures? Do you like them? See sample. Thanks to vhanla for contributing the ligature support.

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.

Not necessarily. And in any case, if you wanted performance, you'd not have chosen Delphi.

Side note 1: for my projects I try to not rely on implementation details of data types. That is, assumption that Datetime1 - Datetime2 is "days between" Side note 2: usually it's more wise to store some meaningful value in DB and convert it to readable form on display (probably one day you'll want to calc some stats about durations - so you'll have to write 'ddd:hh:mm:ss' => Number convertor) Btw, here's function I use in my project: const NoneLbl = '(None)'; // Patterns RightNowLbl = 'less than a minute'; MinsPatt = '%d min'; HoursMinsPatt = '%d hr %.2d min'; DaysHoursMinsPatt = '%d d ' + HoursMinsPatt; // Formats number of minutes elapsed from AFrom to ATo. // If AFrom is 0 returns "None" (process wasn't started) function FormatMinutesSince(AFrom, ATo: TDateTime): string; var Mins: Integer; begin if AFrom = 0 then Exit(NoneLbl); Mins := Abs(MinutesSince(AFrom, ATo)); case Mins of 0: Result := RightNowLbl; 1..MinsPerHour-1: Result := Format(MinsPatt, [Mins]); MinsPerHour..MinsPerDay-1: Result := Format(HoursMinsPatt, [Mins div MinsPerHour, Mins mod MinsPerHour]) else Result := Format(DaysHoursMinsPatt, [Mins div MinsPerDay, (Mins mod MinsPerDay) div MinsPerHour, Mins mod MinsPerHour]); end; end;

So actually, while looking cool and trendy it really is slow and not so cool at all? I got some refactoring to do... gnarf!

Correct.

So, looping an array of records using for v in array, can be significantly more expensive than indexed access using for vx := Low(array) to High(array), given the size of the record?

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Declarations_and_Statements_(Delphi)#For_Statements For to rules are pretty clear: For in rules are a bit general: I am not sure how this would be a problem if we are talking about a loop over a list of objects, as we then would be passing a reference to the list object? I have not really thought about how the variable of a for in loop over an array of records is kept. Do we see a deep copy of the array element in the loop variable, or is there pointer magic involved? I can see how this could be a problem if the reference passed is to a local stack copy.

It's the same issue for both types of for loops. The value of the loop variable is undefined if the for loop terminates normally. In your case that corresponds to the condition never having been met. Unfortunately though, whilst you are aware that there is an issue here, you have not correctly understood what the issue is. That reasoning is incorrect. The loop variable i does not change in case of a normal termination, e.g. the break in your code. Before you consider for in loops I recommend that you correct your misunderstanding of for loops. Executive summary. There is an issue with for loops of both kind. It is the same issue for both kind of for loop. But the issue is not what you have described.

ZEOS 7.3.1-beta svn6845 New Data Types have been added for Firebird 4 https://zeoslib.sourceforge.io/viewtopic.php?f=50&p=157305#p157305 https://sourceforge.net/projects/zeoslib/ https://github.com/marsupilami79/zeoslib There have been a few fixes. Feel free to download, testing, use, submit comments. Michał

@dummzeuchAll these limitations of LockWindowUpdate are well known and noted. Yes you should avoid using LockWindowUpdate if you can and prefer WM_SETREDRAW. Fully agree. WM_SETREDRAW was the first thing I tried and did not work. As Raymond Chen says in the above articles One can well argue therefore, that dragging a Window from one monitor to another is a valid case for using LockWindowUpdate. If it is OK to lock the whole desktop when you do OLE drag&drop it should be OK to lock a single window while dragging it between monitors, just for the time it rescales.

We also do all work in feature branches but our branches are always pushed to remote (and for this reason alone we almost never rebase). We need to have the branches on the remote for several reasons; There are mostly more than one person working on a feature and they need to have access to each others changes. Of course it's up to the individual if they want to create local branches of the feature branches and do their work in those. Personally I just stash and only push when I have something that I know will build. We also to have the branches on the remote in order to have the build server run unit- and integration tests on them. Finally when work on a feature branch is complete we create a pull request to have it merged into the main branch. When QA have tested the build, which they've grabbed from the builder server, someone performs code review on the changes and only then is the PR allowed to be merged into the main branch.

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.

If I am working on a repo in a team then I pull often, otherwise, no - because I know there is nothing to pull How I use Git (modified git flow) I almost always use GUI client - SourceTree - it was best client on OSX at the time, and I got used to it, so I am using it on Windows, too. It has its quirks (every client has) but I never shoot myself in the foot with it master is always production ready develop is development branch both master and develop live on remote (and they are the only ones that live on remote) each feature is new branch, usually very short lived - never pushed on remote, unless they live too long and have to be shared for some reason, but for that I use temporary remote Basic workflow (if working on team) before creating feature branch pull from remote (there will be no merges, because repo is clean - also, I always do pull with rebase) create feature branch from develop a) work on branch, commit... b) if I think there is something new in the repo and I have committed all my feature branch changes, switch to develop and pull with rebase, same with master c) if there were changes rebase feature branch on develop, check if everything works - repeat from a) when work is done on feature branch, pull and rebase feature on top of changes (if there were any), check if it works (if checking takes long enough and depending on potential conflicts with others, pull again, rebase... check...) when all is completed merge feature branch to develop and push to remote If you have problems with workflow, you can setup demo repo and use that to figure out optimal workflow and then apply to real one. If you ever feel like you have messed up something locally, rename (or otherwise backup files you have been working on) repo folder, clone from remote, create new feature branch and copy your changed files back. I said it before, but it is worth repeating. Unless you are GIT DIE HARD, don't use console.

Rather than dumping old unmaintained projects, I'd rather they open sourced elements of the existing offering so that the community can help to improve things. The RTL and associated unit tests would be a good start.

You can easily use a TTimeSpan: program Project1; {$APPTYPE CONSOLE} uses System.SysUtils, System.DateUtils, System.TimeSpan; var StartDateTime, EndDateTime: TDateTime; TimePassed: TTimeSpan; begin StartDateTime := EncodeDateTime(2020, 01, 01, 00, 00, 00, 000); EndDateTime := Now(); TimePassed := TTimeSpan.FromDays(EndDateTime - StartDateTime); WriteLn(TimePassed.ToString()); ReadLn; end. which will output 266.07:29:15.1320000 If you want to have it differently, you can easily define your own format, like function formatTimespan(const timeSpan: TTimeSpan): String; begin Result := String.Format( '%d.%.2d:%.2d:%.2d', [ timeSpan.Days, timeSpan.Hours, timeSpan.Minutes, timeSpan.Seconds ]); end; which will then output 266.07:35:12

@timfrost It doesn't matter if what you do with Project Magician is intended usage or not - it should not crash - period. In case this depends on the project file: Can you send me a copy, please?

The TitleBarPanel is used by the IDE. I guess it was developed to resolve the problem with the disappearing/flickering controls of the IDE title bar (search, layout controls, etc.), It can accommodate Toolbars (including the ActionMainMenuBar) and other controls, so you can place the main menu on the titleBar (see the sample app). And to answer the original question, you would need to manually adjust the Titlebar colors every time there is a style change. This is probably how the IDE styles its TitleBarPanel. @Vincent Parrett I also do not like the overcrowding of TForm and other controls with rarely used properties. (e.g. CustomHint that can be linked to a Balloon Hint all but abandoned - not DPI aware).

After careful review I think REST component doesn't have any option to get the entire header and parameters. Although I was able to get my code working. So, I'll just share to you. RESTClient.BaseURL := 'https://identity.xero.com/'; RESTClient.ContentType := 'application/x-www-form-urlencoded'; RESTClient.Params.AddItem('Authorization', Authorization, TRESTRequestParameterkind.pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); RESTRequest.Resource := 'connect/token'; RESTRequest.Params.AddItem('grant_type', 'authorization_code', TRESTRequestParameterKind.pkREQUESTBODY); RESTRequest.Params.AddItem('code', sAuthCode, TRESTRequestParameterKind.pkREQUESTBODY); RESTRequest.Params.AddItem('redirect_uri', ReDirectURI, TRESTRequestParameterKind.pkREQUESTBODY); Logfile('authorization:' + Authorization + '&grant_type:authorization_code' + '&code:' + sAuthCode + '&redirect_uri:' + ReDirectURI); RESTRequest.Method := TRESTRequestMethod.rmPOST; RESTRequest.Execute; I'm not exactly sure what happen in my previous code but I did transfer the header parameter in the RESTClient instead of placing it in RESTRequest and added the Restrequestparameteroption. Take note also that the Authorization here has a base64 encoding as specified by Xero but during the Delphi encoding it added a linefeed which was also one of the reasons why I keep getting a bad request but I had to remove manually before passing it here. tempFile := 'Basic ' + X.UrlEncode(sClientID + ':' + sClientSecret); sAuthorization := StringReplace(tempFile, #$D#$A, '', [rfReplaceAll]);

We are building a Xero API with OAuth2 using the REST components in Delphi Datasnap. We have been following this Xero API flow: https://developer.xero.com/documentation/oauth2/auth-flow but we are encountering issues on Step 3. It gives me all the time an error of 'invalid_client' but when I tested the values in Postman, I was able to retrieved what is expected successfully with no errors. Here is part of the code. RESTClient.BaseURL := 'https://identity.xero.com/'; RESTClient.ContentType := 'application/x-www-form-urlencoded'; RESTRequest.Resource := 'connect/token'; RESTRequest.Params.AddItem('Authorization', Authorization, TRESTRequestParameterkind.pkHTTPHEADER); RESTRequest.Params.AddItem('grant_type', 'authorization_code', TRESTRequestParameterKind.pkREQUESTBODY); RESTRequest.Params.AddItem('code', sAuthCode, TRESTRequestParameterKind.pkREQUESTBODY); RESTRequest.Params.AddItem('redirect_uri', ReDirectURI, TRESTRequestParameterKind.pkREQUESTBODY); RESTRequest.Method := TRESTRequestMethod.rmPOST; RESTRequest.Execute; I am suspecting it was the base64encoding part, but I was able to correct that one and I was able to successfully test the values in Postman. Is there a way, I can retrieve the full URI or REST parameters that is being sent by this component? I want to see is the entire value that is being sent by the RESTRequest. Is this possible? Thank you!

In theory they are used to preserve the original size and position of controls when they are set to alClient, alTop etc. so when they are set back so alNone at a later time, they automatically revert to their original size and position. Personally I never found that useful and since these values tend to change very often (no idea why, they shouldn't) they pollute the DFM diffs and history.

Delphi IDE uses System.Classes.TStream.WriteDescendentRes to serialize the form/components properties. Property that belongs to the class is handled by System.Classes.TWriter.WriteProperty. However internal property such ExplicitXxx is handled by System.Classes.TWriter.DefineProperty. // TPersistent.DefineProperties defines Explicit properties. and TWriter.DefineProperty encode them. procedure TControl.DefineProperties(Filer: TFiler); begin ... Filer.DefineProperty('IsControl', ReadIsControl, WriteIsControl, DoWriteIsControl); Filer.DefineProperty('ExplicitLeft', ReadExplicitLeft, WriteExplicitLeft, not (csReading in ComponentState) and DoWriteExplicit(edLeft)); Filer.DefineProperty('ExplicitTop', ReadExplicitTop, WriteExplicitTop, not (csReading in ComponentState) and DoWriteExplicit(edTop)); Filer.DefineProperty('ExplicitWidth', ReadExplicitWidth, WriteExplicitWidth, not (csReading in ComponentState) and DoWriteExplicit(edWidth)); Filer.DefineProperty('ExplicitHeight', ReadExplicitHeight, WriteExplicitHeight, not (csReading in ComponentState) and DoWriteExplicit(edHeight)); end; In a nutshell, hooking TWriter.DefineProperty will get you off EplicitXxx: procedure InterceptDefineProperty(Obj: TWriter; const Name: string; ReadData: TReaderProc; WriteData: TWriterProc; HasData: Boolean); begin // do nothing !!! or write a filter to allow certain ExplicitXxx. end; // install the hook : DefinePropertyPtr := GetProcAddress(GetModuleHandle('rtl260.bpl'), '@System@Classes@TWriter@DefineProperty$qqrx20System@UnicodeStringynpqqrp22System@Classes@TReader$vynpqqrp22System@Classes@TWriter$vo'); @TrampolineDefineProperty := InterceptCreate(DefinePropertyPtr, @InterceptDefineProperty);