Alexander Halser

On MacOS and iOS it's called CFBundleURLTypes. CFBundleURLTypes | Apple Developer Documentation Your app registers a url scheme in info.plist and once installed, you can address and open the app through the registered protocol, similar to Windows.

We have just released an open-source Delphi implementation for a HTML-based cross-platform application help system. Information page: Ziphelp - an open cross-platform help format Direct download link: https://www.helpandmanual.com/download/delphi-ziphelp-demo-source.zip About Ziphelp On the surface, Ziphelp is basically HTML in a compressed zip archive, hence the name. Pack any folder with HTML files into a zip archive and you are good to go. But Ziphelp is more than that, it is a protocol based on the standard sitemap protocol, designed to give a help viewer (here: the Delphi implementation) extended information about the content of the help system. That is help context numbers, help keywords, associative keywords, page titles. This information is missing in a standard sitemap.xml. Ziphelp extends the sitemap protocol and enables direct communication of an app with the help system. The Ziphelp protocol is not just for zip archives. It works inside an archive, with uncompressed folders or with HTML content loaded directly from a website. A Delphi desktop app may be deployed with local application help, uncompressed, zipped or embedded. A mobile or web application might not ship with local HTML content, but refer to an online version instead. The mechanism is the same in both cases and the TZiphelp component implements this for Delphi. Demo Application A demo app for VCL and FMX (Win/MacOS) is included. The demo builds on standard Delphi components (TWebBrowser) to display the help system.

eWriter is an always compressed single-file format, created by our tool Help+Manual. It has a couple of advantages over simple zipped HTML, but is a proprietary format. Ziphelp, on the other hand, is an open protocol. Maybe zipped, maybe not, you choose. You can create it with standard tools and view it with Delphi's on-board components. That's the entire point of this endeavour: a format/protocol for application help, that is open on both ends (creator and viewer) without dependency on any particular tool. Between 3 and 20 lines of code. Check out the VCL example in the download file. It implements all help methods including F1 help with standard TControl.HelpContext and TControl.HelpKeyword properties, plus a validity check [of context numbers] and iteration of parent controls. If you want to skip the latter, you are basically down to 3-5 lines of code. Does not apply. If you want to zip-pack your HTML content, you most probably distribute it with your app. If you choose the online version, then there's no zip.

A personal preference, no technical obstacle. A mobile app I want to be lean and small. So, I'd put the help system on the app's website and let it refer to the online version, displaying the help in the regular system browser. The demo has an option that illustrates this (though the demo uses its internal TWebBrowser to display the result). In other words: I would not use the zip functionality for a mobile app and rather remove the reference to system.zip in ziphelp.pas for those platforms with a compiler switch (plus the single line that uses it). The rationale behind this consideration is that a mobile app goes to one of the stores and automated updates are very likely, minimizing the risk of a version mismatch between app and help. Furthermore I expect a mobile device to be online anyway. Both points may not apply to a desktop app. But it's really a personal preference.

No, it is not derived from CHM. Because CHM is basically Windows only and not cross-platform. Yes. plain HTML5 and based on the regular "sitemap" XML schema. When you create CHM files for a Windows application, you typically use an authoring tool for this and don't craft the HTML in Notepad. Those authoring tools which create CHM files usually create plain HTML5 as well. The example help you see in the demo project was created with Help+Manual, it's plain vanilla HTML5 and Javascript. But not just Help+Manual produces this output, Madcap Flare does, Adobe Robohelp does, you name it. And most authoring tools offer some kind of syntax to use the plain HTML5 output for context-sensitive help. Unfortunately, everyone has their own syntax, there is no established standard. And because of a missing standard, there are no viewer applications, as long as everyone does their own thing. Ziphelp is an attempt and a ready-to-use solution for this dilemma. It is as open as possible, because it is based on the standard sitemap protocol. This is the same sitemap.xml that you use on your website to help Google index it. Ziphelp is basically a legal extension of this protocol. Open for everyone to produce content that includes a Ziphelp sitemap and open for everyone to create an HTML viewer that can read it. To give it a head start, we have created a freely distributable HTML viewer that reads the Ziphelp protocol (https://www.helpandmanual.com/ewriter/). Some people prefer this solution because it's less work for them. But for Delphi developers, I think that a native cross-platform implementation is more appealing. Here, everything is under your control and your application can interactively question the help system if it actually "supports help context number 45327" or if that number is outdated in the UI of your app (and you should clean it up, but at least you don't let your end users run into an 404 error). This interactivity is missing even with CHM files. So, here you go. A free Delphi implementation that supports HTML5 in a zip archive, uncompressed HTML or web-based content. It all works with the same protocol and the same mechanism, on all platforms. You can create this HTML5 help system with our tool Help+Manual, of course. But you don't have to. If you prefer a different authoring tool, go for it.

The project now has been moved to Sourceforge: Delphi Cross-Platform Application Help download | SourceForge.net

For a new FMX app (Win/Mac only), I need some UI controls that go beyond the simple features that the Delphi built-in controls have to offer. One of them is a color picker component. There are very few color picker tools available for FMX and creating a new one turned out to be more work than anticipated. That's why I put mine on SourceForge. If you require a similar control, feel free to use it as you please. Delphi FMX Color Selector download | SourceForge.net I hope to get some feedback on the component as well, because it currently has 2 flaws (explained below). To use the color picker, reference the unit and call one of the two global methods ColorDropdown and ColorButtonDropdown. The first method is generic and can be used with any control, the second expects a standard TColorButton. I have implemented the component in a TForm that is dynamically created at runtime. No component installation required. This was an important point [for me], because I need a few more very specialized popup controls that are supposed to be placed in this form. Using a simple TForm makes it much easier to design them than doing everything in code. Current issues: One of the obstacles I came across was a drawing bug in TGrid, at least with Delphi 11.0 (maybe fixed in later versions). The grid is/was designed to fit exactly 10 rows and on the first display, it properly shows all 10 rows. Close and reopen the popup control, and the original 10 rows have shrunken to 9 visible rows. I fixed it by making the grid tall enough for 11 rows and filled the whitespace below by moving the opacity slider up. Looks fine and works so far, but if someone has an idea how to fix the visible rows in TGrid, I would appreciate a feedback. The second issue is the color picker. It's implemented as a picture that you can drag & drop anywhere on the parent form to pick a color. This method is safe, but not 100% intuitive. A click-button-then-select-color function would be nicer. So, if anyone wants to spend time on that, I appreciate it. Apart from that, have fun trying it - demo application is included.

The color selector has been updated to v1.3 on SourceForge. A couple of features added, some bugs fixed. https://sourceforge.net/projects/delphi-fmx-color-selector/files/

It really does? I wasn't aware of that. Maybe we have just been lucky and were always using that one DrawImage method, that works. We draw pictures with the GDI+ function below. Bounds is the destination rectangle, already calculated in device pixels. procedure DoGDIPlusDraw(DC: HDC; bmp: TBitmap; bounds: TRect); var gpgraphics: TGPGraphics; gpimage: TGPBitmap; Width, Height: UINT; begin gpgraphics := TGPGraphics.Create(DC); gpimage := TGPBitmap.Create(bmp.Handle, bmp.palette); try Width := gpimage.GetWidth; Height := gpimage.GetHeight; gpgraphics.SetInterpolationMode(InterpolationModeHighQualityBicubic); // 7 gpgraphics.DrawImage(gpimage, bounds, // destination rectangle 0, 0, // upper-left corner of source rectangle Width, // width of source rectangle Height, // height of source rectangle UnitPixel); finally gpimage.Free; gpgraphics.Free; end; end;

Without trying your example ... When you print an image, the screen DPI doesn't matter at all. You are dealing with printer DPI instead. Nothing else. TGPBitmap loads the PNG image and that image has a defined size in pixels. With TGPBitmap.DrawImage the picture is rendered onto a Windows device, which can be a screen device or a printer device. For GDI+ this is more or less the same (some technical printer details omitted). Fact is, GDI+ does the stretching and resampling to make the image fit into the rectangle you specify. And that target rectangle must be in device pixels. If the device is a printer, get LOGPIXELSX from the printer canvas and relate it to 96 dpi (= Windows standard display resolution at 100%). // get printer device DPI DC := GetDC(Printer.Canvas.Handle); try nLogPx := GetDeviceCaps(DC, LOGPIXELSX); memo1.Lines.Add(Format('Printer Device: %d', [nLogPx])) finally ReleaseHDC(DC); end; rectImage.Create( MulDiv(10, nLogPx, 96), MulDiv(10, nLogPx, 96), MulDiv(100, nLogPx, 96), MulDiv(100, nLogPx, 96) ); (The code example is untested, typed from memory. Point is, get the resolution of the printer canvas, not the screen.)

That doesn't apply to checkboxes alone. Radio buttons, radio groups, checked menu items, actions, OnResize events, you name it. Some forms have plenty of details to initialize. We have been using update counters for that, since more than 20 years. Like, every TForm that does some initialization which may auto-trigger events, has an IsUpdating property. The setter increases/decreases the value, the getter returns a boolean. If IsUpdating returns true (> 0), the checkboxes do not execute their OnChange event, manually arranged panels do not update, etc. constructor TForm1.Create(AOwner: TObject); begin inherited; FIsUpdating := 0; IsUpdating := true; //increases FIsUpdating try //do your init here finally IsUpdating := false; end; end; procedure TForm1.SetIsUpdating(value: boolean); begin if value then inc(FIsUpdating) else dec(FIsUpdating); end; function TForm1.GetIsUpdating: boolean; begin result := FIsUpdating > 0; end; A counter is more flexible and error-tolerant than using the csUpdating flag in ComponentState. It can be used to update corresponding controls in an OnChange event as well, without triggering their OnChange. The counter enables nested IsUpdating without worries. The only thing to remember is to consequently use try-finally.

PDFium lib does all you need. We use it with an internal application that deals with PDF pages. Add or remove pages, split pages into several smaller ones, re-combine smaller pages into one printer page. PDFium can extract text as well.

tested with polardark_win and polarlight_win styles I confirm that it works for me with the styles included in Delphi and those premium styles available for download when you have an active subscription. That's why I asked the OP where the dark styles origins from. Maybe it is an older style? My argument is that if a simply outdated style compiles just fine and looks good on screen, but generates potential runtime issues that may cause problems I would have never expected and that are difficult to find, then we're in for future problems with FMX styles

ChildForm is not released, StyleBookLight don't contain data Where do you see a problem here? Form2 is auto-created and auto-released, StyleBookLight is not required to produce the problem. I had some similar problem using an old 10.2 style That worries me ... what happens if a project that includes a TStylebook with a previously up-to-date style gets updated to a new Delphi version? Does that mean it compiles just fine but fails at runtime with mysterious errors? How does one test an app for potential problems like the one above? I'd like to know where it comes from before using FMX styles.

Fascinating example... thanks a lot! I am currently experimenting with FMX styles and very much appreciate this. It's got something to do with the dark style - the style itself damages the runtime functionality. I can duplicate the issue with Delphi 11.0, both 32 and 64 bit, it is reproducible with the dark style (only). Switching back to the light style makes it work again. My first guess was that it has to do with TStyleBook. It is apparent that the second form does not pick up the style, so I thought it may have to do with this issue. But this is not the case. So I loaded my own dark skin into your dark stylebook. Guess what? Works like a charm, despite not applying the style to the second window. There is, that's for sure, some flaw in the dark style you are using. Fascinating this is possible at all... I did not think it was. Where does your dark style come from?

FMX doesn't auto-capture the control the mouse went down on. But you can do this manually, either by TForm.MouseCapture (that's for the form itself) or with TForm.SetCaptured(AnyControl) - this is for a particular control on the form. procedure TForm1.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin if (Sender <> self) then SetCaptured(TControl(Sender)) else MouseCapture; memo1.lines.add(Sender.Classname + ' mouse down'); end; procedure TForm1.FormMouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin ReleaseCapture; memo1.lines.add(Sender.Classname + ' mouse up'); end; Setting the mouse capture is important if you do anything in MouseDown that interacts with the control being clicked. Without capture, the user may click (mouse-down) on Panel1, move it, and release it on Panel2. The MouseUp will come from Panel2 in this case, or no mouse-up at all. By setting the mouse capture, you are guaranteed that you'll receive a MouseUp from that control that is being captured. VCL does this automatically, FMX does not. If you don't need the MouseDown on form level, but just for particular controls, use TControl.AutoCapture instead.

I was about to suggest to create a custom inplace editor. But the form that contains the TStringGrid does get KeyDown notifications, even when editing content. Out of curiosity, I wanted to know the internal structure of the grid, when it's editing. procedure TForm2.FormKeyDown(Sender: TObject; var Key: Word; var KeyChar: Char; Shift: TShiftState); var ctl: tfmxobject; s: string; begin if key = vkF5 then begin ctl := activecontrol; while ctl <> form2 do begin s := '> ' +ctl.classname + S; ctl := ctl.Parent; end; showmessage(s); end; end; It says: TStringGrid > TGridScrollContent > TDefaultEditor So if you check the OnKeyDown on form level and detect that ActiveControl is a TDefaultEditor with a TStringGrid as grandparent, you should be all set. Aren't you?

I need some FMX functionality in a VCL app. An FMX Windows DLL should handle the task. So far, the (FMX) DLL is working, but... Loading a TBitmap in the initialization of the DLL fails. The host application (actually the DLL) comes up with a general error. Loading the TBitmap at a later point in time (e.g. triggered by the host app) works. Unfortunately, the real DLL is a bit more complex and stripping all the "initialization" from all units is not an option. Static vs. dynamic loading of the DLL by the host VCL app does not make a difference. I've also tried ShareMem (not convinced it would change anything), but to give it a try: same result. Stripped down to the core, the entire DLL code is in the screenshot below. To me, it looks as if the GDI+ or DirectX environment is not loaded, when the DLL initializes. Is this a general limitation or could that be worked around by forcing earlier loading of GDI+/DirectX?

You are certainly right. But the real DLL is more complex and involves 3rd party components, which happen to load TBitmaps in the initialization. Quite common, I'd say, and I wouldn't have considered it scary. But obviously, it is

Si Señor! Winapi.GDIOBJ instead of FMX.Graphics does the trick. And saves a few megabytes. Thank you very much for the hint, Uwe! To sum up the solution... If an FMX DLL requires drawing capabilities in the initialization (that requirement might be triggered by 3rd party units), then the VCL host application must load GDI+ before loading the DLL: In the VCL host app, include Winapi.GDIOBJ to init GDI+ Load the FMX DLL dynamically (static linking would cause the DLL to load first, before host can load GDI+) If the host app is FMX and not VCL, it loads GDI+ by default. In this case, point (1) is void, but dynamic loading of the DLL is still required.

Update, a partial solution, and a question... Observations with an FMX host app + FMX dll: The FMX DLL requires GDI+/DirectX in the intialization section. It creates an FMX.TBitmap and loads an image. To do this, it requires a GDI+/DirectX canvas. Such a DLL cannot be statically linked, fullstop. Not even with an FMX host application, despite the FMX host does initialize GDI+/DirectX. The reason is that statically linked DLLs get loaded before the host app can initialize GDI+/DirectX. Solution for FMX host + FMX dll: link the DLL dynamically, let the host app initialize GDI+/DirectX (as it does by default), then load the DLL. Result: the initialization of the DLL works, because GDI+/DirectX is already available (loaded by the FMX host). Observations with a VCL host app + FMX dll: It's obvious that GDI+/DirectX must be initialized by the host app before the DLL gets loaded. Dynamic DLL loading is therefore a must. The VCL host does not - at least not by default - initialize GDI+/DirectX, because it does not require it. Question: can we force the VCL host to deliberately load GDI+/DirectX, which is required by the DLL? Answer: yes, we can by including FMX.Graphics into the VCL section. Technically, that works (and the compiler does not complain). VCL host app test unit, modified: Note, that the VCL app references FMX.Graphics. This adds about 7mb to the EXE and seems to work. Is this a reliable construct? Or is there a different way to invoke (just) GDI+/DirectX in the host app, without all the FMX.Graphics overhead? unit VCL_hostUnit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, FMX.Graphics; { <--- This works and intializes GDI+/DirectX for the DLL. But will this work reliably? } type TVCLForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; TLoadImage = function(Filename: PChar): Boolean; var VCLForm1: TVCLForm1; dllHandle: Cardinal; LoadImageFunc: TLoadImage; implementation {$R *.dfm} function LoadDLL: Boolean; begin dllHandle := LoadLibrary('TestDLL.dll') ; @LoadImageFunc := GetProcAddress(dllHandle, 'LoadImage') ; end; procedure TVCLForm1.Button1Click(Sender: TObject); begin if LoadDLL then LoadImageFunc('C:\Users\Alexander\Documents\Embarcadero\Studio\Projects\fmx-dll-test\test.png') else Showmessage('DLL not loaded'); end; initialization dllHandle := 0; finalization if dllHandle <> 0 then FreeLibrary(dllHandle) ; end.

Hello programmerdelphi2k! I should have been more precise: Delphi 11.0 Win32 (not 64 bit) The DLL is 100% FMX, so TBitmap is an FMX.Graphics.TBitmap The host app is 100% VCL Host and DLL do not exchange bitmaps, nor other complex data structures. They exchange PChars and function results. When the host app starts and the DLL loads, I get the message "Load DLL" and after that: "Exception EAccessViolation in Module TestDLL.dll at 0000842F." Host app (VCL 32 bit, 1 form): unit hostUnit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; function LoadImage(Filename: PChar): Boolean; external 'TestDLL.dll'; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin LoadImage('C:\Users\Alexander\Documents\Embarcadero\Studio\Projects\fmx-dll-test\test.png'); end; end. DLL Code: library TestDLL; uses FMX.Forms, FMX.Graphics, FMX.Dialogs; {$R *.res} function LoadImage(Filename: PChar): Boolean; var dummy: FMX.Graphics.TBitmap; begin dummy := FMX.Graphics.TBitmap.Create; dummy.LoadFromFile(Filename); dummy.Free; Showmessage('Image loaded'); end; exports LoadImage; var dummy: FMX.Graphics.TBitmap; begin Showmessage('Load DLL'); dummy := FMX.Graphics.TBitmap.Create; //This line included, the DLL fails to load: // dummy.LoadFromFile('C:\Users\Alexander\Documents\Embarcadero\Studio\Projects\fmx-dll-test\test.png'); dummy.Free; end. HostApp.zip

I am currently working on some legacy code that uses simple TLists with object references and custom sort. This has worked and still works perfectly in 32 bit. But in 64 bit output, the list is not sorted (correctly), although it compiles without any errors. The form contains a couple of TShapes with different widths. The code below is supposed to sort and rearrange them by width. In 32 bit, the sort is ok. In 64 bit it's random. In fact, the function SortByWidth is called with item1 and item2 being the same (here: pointing to the same TShape). I am concerned and want to understand what's going on and why this does not work in 64 bit. There are more modern ways to sort a TList or use dictionaries. But this is legacy code that contains sorting functions of this kind in several places. procedure TForm2.BtnSortClick(Sender: TObject); function SortByWidth(const item1, item2: TShape): Integer; begin result := item1.width - item2.width; end; var AList: TList; i: Integer; begin AList := TList.Create; try for i := 0 to ComponentCount-1 do if (Components[i] is TShape) then AList.Add(Components[i]); AList.Sort(@SortByWidth); //what is wrong about this in 64 bit? for i := 0 to AList.Count-1 do TShape(AList[i]).Top := 30 + (40 * i); finally AList.Free; end; end;

@Uwe Raabe & Günter: Thank you, that does the trick! This saves me a lot of code-rewriting 🙂 function SortShapesByWidth(const item1, item2: TShape): Integer; begin result := item1.width - item2.width; end; procedure TForm2.BtnSortClick(Sender: TObject); var AList: TList; i: Integer; begin AList := TList.Create; try for i := 0 to ComponentCount-1 do if (Components[i] is TShape) then AList.Add(Components[i]); AList.Sort(@SortShapesByWidth); for i := 0 to AList.Count-1 do TShape(AList[i]).Top := 30 + (40 * i); finally AList.Free; end; end;

The heading is not a typo. I've taken over Mac development from a colleague who recently left, so Delphi/Mac is pretty new to me. I'm running Delphi 10.4 Seattle with all patches and have a new Macbook running Monterey with Xcode 12.5.1. My basic "hello world" test app compiles and deploys successfully. But it doesn't start on the Mac. When started manually, it flickers for a moment, then terminates. PAServer reveals the underlying problem: dyld[xxxx]: Library not loaded: ?^??? Referenced from: /Users/alexander/PAServer/scratch-dir/Alexander-MacProfile/MacTest.app/Contents/MacOS/MacTest Reason: tried: '?^???' (no such file) The app obviously has a reference to "?^???" which is not found. But where does this come from? My current configuration: Delphi 10.4 with all patches MacOS Monterey with Xcode 12.5.1 (after realizing that Xcode 13 is not compatible I managed to install and run 12.5.1) Delphi SDK Manager: MacOSX 11.3 The app compiles and deploys successfully, both in Release and Debug mode. It just doesn't run. I'm pretty much stuck here... Google delivers plenty of results for "library not loaded" but none of them deals with a string called "?^???". PS: When changing the encoding of the (very simply) main unit from ANSI to UTF8, this slightly affects the error message. The UTF8 variant looks for a library called "?^;?[" instead of "?^???". Any hints where to look for this?