Leaderboard

I found this in my usenet archives about the evaluation order:

@FPiette do you know https://github.com/neslib/Neslib.Xml? I switched some of my xml parsing from Delphi's native parser to Neslib.Xml and it resulted in around 35x-40x faster parsing (17-20 seconds versus <= 0.5 seconds).

Uh, both the subject of this thread and your original question specifically asked for async dialogs: So I guess I'll let someone else try and answer your question.

I'm pretty sure it was the other way round. AFAIK it's still written in Delphi.

Hmm, it's rare to see SO many bad practices in one piece of code...

It's very simple take a look at TImage.SetBitmap. The TImage object will assign the bitmap to the internal bitmap and will not take the ownership over of the parameter. You've to write: var lbm: TBitmap; begin if OpenDialog1.Execute then begin Image1.Bitmap.LoadFromFile(OpenDialog1.FileName); lbm:=ConvertToGrayscale(image1.Bitmap); try Image2.Bitmap:=lbm; finally lbm.Free; end; end; end;

There's a good reason for that - implementing modal dialogs on Android the same way as on Windows is practically impossible. The workaround is to use async dialogs. Developers do this on Windows all the time - from one form, show another. When the user takes some action on the secondary form, do something based on that action, and close the form. The primary form will still be there when they get back 🙂 If the primary form needs to "know" what happened on the secondary form, you could expose a property or event handler on the secondary form which the primary form can examine, or handle.

No, there is not. I create my own table manually, using a combination of Microsoft's Message Compiler and XN Resource Editor (to tweak the output from mc.exe) to produce a .res file that I then link into my project

Only because you were explicitly looking for CommandType=hcUnknown, which was not necessary to begin with. You could have simply done this instead: isPutOrPatch := (ARequestInfo.CommandType = THTTPCommandType.hcPUT) or TextIsSame(ARequestInfo.Command, 'PATCH') ; And that would have still worked fine with the CommandType change. Indy's release numbers were broken when Indy migrated from SVN to GitHub (issues #292 and #328), and that problem has not been addressed yet, but I do intend to ... some day, when I have time for it. However, the code is now live in Indy's master branch, and Lazarus' OPM has been updated to use this version (they have labeled it as version 10.6.2.4072). A future version of Delphi will pick up the change whenever Embarcadero decides to update their copy of Indy (usually in major IDE version releases).

It is difficult to explain what needs to be changed exactly, when you have not shown the actual code that is erroring. However... Make sure your handler/override is using the general-purpose Char type, and not using AnsiChar directly. Prior to Delphi 2009, Char was an alias for AnsiChar, and as such it only supported 255 values max, which is also the max number of values that that a Set supports. Since Delphi 2009, Char is now an alias for WideChar, so it is too large to use in a Set. If you try, the Char value has to be truncated from 16 bits to 8 bits, which is what the warning is about. The CharInSet() function was introduced to hide that warning, but not the truncation. Prior to Delphi 2009, string was an alias for AnsiString. Now, it is an alias for UnicodeString. ShortString is a fixed-length ANSI string, always has been, and still is. Assigning a ShortString to an AnsiString is a loss-less operation, but assigning a ShortString to a UnicodeString can potentially cause data loss. So, the compiler now requires an explicit typecast whenever you assign an ANSI string to a Unicode string, or vice versa, indicating that you understand the risk. You really shouldn't be using ShortString for anything other than interacting with external legacy systems. This means your code is declaring function parameters that do not match what the compiler is expecting. This is most commonly seen in event handlers that are using the wrong parameter types.

Also have a look at Embarcadero's Migration and Upgrade Center

uses FMX.DialogService.Async; procedure TestAsyncDlg; begin TDialogServiceAsync.MessageDialog('Hello Android!', TMsgDlgType.mtInformation, [TMsgDlgBtn.mbOK], TMsgDlgBtn.mbOK, 0); end;

This code exhibits undefined behaviour. In an expression like a + b, a and b can be evaluated in either order. The language does not mandate that order. If you want to make your code well defined the. You need to evaluate the function on one statement, and then perform the addition in another. finalValue := ResultIsFive(index); Inc(finalValue, index);

For Android, this is the only way I've found that will quit completely and remove the task from the "recent items" list: https://github.com/DelphiWorlds/Kastri/blob/64a5600e0845862f3e3991cd1708dee82a65ff45/Core/DW.Android.Helpers.pas#L561 For iOS, it's bound to have your app rejected if it is on the App Store, otherwise: https://developer.apple.com/library/archive/qa/qa1561/_index.html

And here is a doAdvancedDrawItem method that works with older Delphi versions (tested with Delphi 2007) procedure THeaderMenuItem.DoAdvancedDrawItem(Sender: TObject; ACanvas: TCanvas; ARect: TRect; State: TOwnerDrawState); begin {$IF declared(TStyleManager)} ACanvas.Brush.Color := TStyleManager.ActiveStyle.GetStyleColor(scPanelDisabled); ACanvas.Font.Color := TStyleManager.ActiveStyle.GetStyleFontColor(sfWindowTextNormal); {$ELSE} ACanvas.Brush.Color := clDkGray; ACanvas.Font.Color := clWhite; {$IFEND} ACanvas.Font.Style := [fsBold]; ACanvas.FillRect(ARect); ACanvas.TextRect(ARect, ARect.Left + 3, ARect.Top + 3, StripHotkey(Caption)); end; To get it to compile with Delphi 2007, just remove the unit namespaces from the uses list. Adjust the colors to your liking.

Just in case anybody is interested, here are two overloaded constructors that make it much more convenient to insert such group headers into a menu: interface type THeaderMenuItem = class(TMenuItem) public // default constructor as above constructor Create(AOwner: TComponent); overload; override; constructor Create(_ParentMenu: TMenuItem; _Idx: Integer; const _Caption: string); reintroduce; overload; constructor Create(_ParentMenu: TMenuItem; _InsertBefore: TMenuItem; const _Caption: string); reintroduce; overload; end; implementation constructor THeaderMenuItem.Create(_ParentMenu: TMenuItem; _Idx: Integer; const _Caption: string); begin Create(_ParentMenu); Caption := _Caption; _ParentMenu.Insert(_Idx, Self); end; constructor THeaderMenuItem.Create(_ParentMenu, _InsertBefore: TMenuItem; const _Caption: string); var Idx: Integer; begin Idx := _ParentMenu.IndexOf(_InsertBefore); Create(_ParentMenu, Idx, _Caption); end; And, as I just found out: Don't forget to set the Style property of the menu to msOwnerDraw set the OwnerDraw property of the menu to True!

Have a look at this: In addition to SAX parsers you may want to consider XmlLite. XMLLite is a good alternative to SAX on Windows. See the note about push and pull parsers. Similar speed and much easier to program with. And there is a Delphi wrapper (just a single unit to add to your project). In my experience XMLLite was very fast. Microsoft is using XMLLite to parse SVG files.

Sampling profiler will give you better insight. https://www.delphitools.info/samplingprofiler/