in the case of error, you can get what would’ve normally been in the contentstream from the ExceptionObj.ErrorMessage property. So you can use something like the following if you want to get the content response regardless of http response code (untested):
var
FResponseStream: TStringStream;
FRequestURL, Content : String;
begin
//.... etc etc
try
FIdHTTP.Get(FRequestURL, FResponseStream);
Content := FResponseStream.DataString;
except
on E:EIdHTTPProtocolException do
Content := E.ErrorMessage;
end;
// At this point, "Content" contains the response body, both for
// successful (200) as well as other response codes.
//.... etc etc
end;
A long time ago, Lars Fosdal wrote this on the Delphi G+ group:
It really is beyond me why there is no Project.rc file which includes
Project.version.rc
Project.icon.rc
Project.themes.rc
Project.manifest.xml
and so forth.
That way, the .res file would be a compile-time thing (or even a thing of the past) – and the resource linker would assemble the various bits from their individual sources.
It has been an issue forever. Vincent Parrett correctly commented that if you clean out too much out of the Project.res file, the IDE gets confused:
The only thing it is used for is version info and the mainicon (the IDE gets confused if don’t do that).
Like many of the G+ commenters, I’ve switched to script based resources for my own projects a long time ago. That’s also the reason why I forgot: this approach just works for any Delphi version.
This post is a reminder to self to see if the IDE has finally refrained from doing Project.res handling itself.
It is used inside the TAppliation.Idle to fire the (undocumented) TApplication.DoActionIdle method. When the value is zero or less, then each Idle call will result in an DoActionIdle call in turn calling TCustomForm.UpdateActions for any visible form.
In theory, the OnUpdate method for each action can even be called multiple times (because multiple controls on visible forms can point to it), but the real culprit is that TApplication.Idle as it can be called from these places:
TApplication.DoApplicationIdle
TApplication.HandleMessage (in a loop from TApplication.Run)
TCustomActionMenuBar.ProcessMenuLoop (in a loop)
TCustomRibbon.DisplayKeyTips (in a loop)
The last three (especially HandleMessage) can be disastrous as they can be called a lot (for instance when moving the mouse), and more often than not, the OnUpdate event handlers aren’t exactly CPU friendly.
A while ago I bumped into an application where the OnUpdate event handler for one action was called half a million time in under 5 minutes.
This clearly indicated a huge problem (besides using a full CPU core slowing down the application) as apparently something was broadcasting Windows Messages like crazy.
Investigating and Solving the message flood is on the back-log with a reasonably high priority, but the highest priority issue was fixing the high CPU usage in the first place.
Apparently more users suffer from this, as there is a Vcl.Forms.TApplication.ActionUpdateDelay property which TApplication.Idle uses to call the Windows API function SetTimer to rate-limit the TApplication.DoActionIdle call tree. Luckily SetTimer does have documentation on the unit of ActionUpdateDelay: it’s milliseconds.
I’ve set it to 10 as that updating the actions ~100 times a second is fast enough for this application.
At the time of writing: The Selective Debugging package currently supports Delphi XE to Delphi 10.1 Berlin. It can be downloaded here: SelectiveDebuggingSetup.zip [WayBack]
If when setting up Continuous Integration (CI) with Delphi and you get errors like E2202"Required package 'rtl' not found" or F1027"Unit not found: 'System.pas'", then something is wrong with your library path on the CI server.
Before going into the details of why, the quick solution is to set either of these environment variables in your build script
put your resources in a text RC file that can be compiled through a resource compiler
add these to your Delphi project via the project manager, so it generated RcCompile elements which instructs the build process to run the resource compiler first:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters