XylemFlow

FMX mostly does a very good job of antialiasing graphics, however I notice that quality of TCanvas.DrawBitmap is poor when the destination rect is smaller than the source rect. I'm running on Windows for now. This is especially obvious when the image contains thin lines as the subsampling causes parts of the lines to disappear. I'm looking for a way to improve the quality without compromising too much on runtime. So ideally I'd like it to be done on the GPU. I feel that this is a job that the GPU should be doing. Below is an example with 3 different methods. The last method is my own code, which shows what I'm trying to achieve but is not done on the GPU and so is not as fast as I'd like it to be. It also won't work if I want to include some rotation as well as scale using TCanvas.Matrix. I have also tried changing the HighSpeed flag in the DrawBitmap function, but it doesn't seem to make a difference (it does when upscaling an image but not when downscaling). See the attached project code example. Is this something that GPUs can normally do and if so, why isn't DrawBitmap doing it? Is there an alternative that will also work on different platforms? If I reduce an image in something like Inkscape it will do a much better job, although I'm not sure if the GPU is being used for the downsampling. Draw_bitmap_small.zip

I need to be able to draw several objects to a form or TImage TCanvas, including lines, circles, polygons, text, etc and have them drawn as a group with a single opacity. If I draw them separately then it won't look correct where they overlap. I currently do this by drawing the objects to an offscreen TBitmap canvas with full opacity and then drawing the TBitmap to my form or TImage TCanvas with the opacity I want. However, this is slower and uses more memory. I'd also like to use Skia in future, but I understand that drawing to offscreen bitmaps is slower since it doesn't use the GPU. Is there a method to group objects in this way in default FMX or Skia without using an offscreen bitmap?

Unfortunately I need to draw everything directly on a single TCanvas. I cannot do it by layering controls on top of each other. One reason is because I need to export the resulting image. By sharing the same opacity I mean that they should be semi transparent and so show previously drawn objects underneath

If you want to change the style of the whole window then it's easier to download a theme style. You can download FMX styles or a VCL style and convert it to a VCL style using Bitmap Style Designer. You can then modify the style if needed. The critical part of the style for the window is windowborderstyle.

When I select all the text in a TNumberBox (Ctrl+A or drag over the text) and hit Delete, the value gets reset to the Min value and the OnChange event is triggered. This is strange because clicking at the end of the number text and deleting all the characters one at a time until none are left doesn't do the same. A user is likely to want to quickly delete the text, type in a new value and hit enter. However, this doesn't work because the value automatically gets reset to the Min value when all the text is deleted at once. Is there any way I can prevent that? Note that I am running for Windows 32-bit.

It seems that this isn't only an issue with TNumberBox. TSpinBox does it too. I think anything descended from TCustomEdit. My best guess is that the control is validated when deleting selected text because there is no caret shown.

Thanks Mike. Setting VertIncrement to 0 solves the first issue. I have also set HorzIncrement to 0 so that dragging selects the text without changing the value. Unfortunately that means that the arrow keys and mouse wheel no longer increment the value, but I was able to implement that myself using the KeyDown and MouseWheel events. So yes, it is a bit of a mess, but otherwise it works ok. One advantage is that it automatically prevents non numeric characters and supports copy and paste. Ctrl+A does work for me.

I've not tried VCL, only FMX. Interesting that it's not happening in VCL though. Also, I'm using 11.2. I have some boxes ranging from -360 to 360, some from -180 to 180 and some from 0 to 100. They all behave the same way.

I have created a TFrame at design time using the form designer. I then create several instances of the frame at run time. Is there a way to set a property of the underlying TFrame for all instances at once instead of having to iterate over all instances? For example, when a user changes the language at run time the captions and hints of the buttons in the TFrame need to be updated for all instances.

I have set the form's Transparent property to True. I have a TImage covering the form, which also has some fully transparent areas. When these transparent areas are clicked the window underneath is selected and the form loses focus. I'd like the form to keep focus and the TImage OnMouseDown event to trigger. So far the only solution I've found is to place a slightly opaque TRectangle over the form, however this is not ideal because it requires unnecessary alpha blending and also changes the colours slightly.

Funny. That bug was reported by me, but I hadn't considered that it would cause problems in my demo.

I would set the Form's Transparency property to True. https://docwiki.embarcadero.com/Libraries/Sydney/en/FMX.Forms.TForm.Transparency Now you can put a TRectangle on the form and align it to client. Set its XRadius and YRadius to round the corners. Set it's Fill colour to that of the form. The rounded areas in the corners will not be considered part of the form. Clicking them will select object behind the form. The down side is that the form's title bar will be missing, but you could perhaps recreate it with some additional controls. But for a splash screen I guess you don't want the title bar anyway. I have the opposite problem. I have a transparent form and want the transparent areas to be considered part of the form and not select windows behind. The best way I've found is to place a very slightly opaque TRectangle over the form, but this isn't ideal. I'd like a method to make it fully transparent.

This is a rather complex issue that I need help resolving. TImage Mouse Move and Mouse Up events are not triggered after showing a modal window from a TMainMenu item, but only when a certain style is applied to the form. Attached is a project for replicating the issue. Mouse events are recorded with incrementing counters. Any help would be appreciated. I'm using Delphi 11.2 and running in Windows 10. Steps: 1. Build for Windows 32-bit and run 2. Select Dark mode with the check box, which will apply the style to the form 3. Click Show 2nd Form in the File menu, which will show a 2nd form as a modal window 4. Close the 2nd form. The main form will regain focus 5. Move the cursor over the image and the counter won't increment Observations: 1. The Mouse Down event is triggered after closing the 2nd window, but the Mouse Up event isn't. This causes a miss match in the counters. 2. In the default light mode the menu items activate on mouse up, but in dark mode they activate on mouse down. Perhaps the main menu is still owning the mouse up and mouse move events somehow after closing the window because of this? 3. A TMenuBar does not have the same issue, even though its items are activated on mouse down 4. I can't find anything in the style editor for the dark style that I could edit to fix the issue. 5. I could try putting something in the main form's OnActivate event to force the Image to regain ownership of the mouse events, but nothing I try seems to work. Dark Mode Demo.zip

I'm using the Alt key in my application in an unusual way. It's used to modify how an object is dragged around on a canvas. The issue is that when pressing the Alt key after clicking down on the mouse button, the mouse up event and key up events are not triggered. I assume that this has something to do with accelerator keys for the TMenuBar. However, I don't want accelerator keys for the menu and they don't work in FMX anyway. I had the same issue in a previous version of my application that was developed in VCL. That was solved easily with the following, which then prevents the menu from reacting to the Alt key. procedure TForm.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin // Prevent Alt key selecting the menu if Shift = [ssAlt] then begin Key := 0; Exit; end; // Other key processing code end; However, the same doesn't work in FMX with TMenuBar. I've tried setting Key to 0 and KeyChar to #0 but the issue remains. Note that the same issue does not happen when using TMainMenu, but I'm forced to use TMenuBar for various reasons. Does anyone have a solution? I'm running in Windows 32-bit but would also want it to work for macOS.

https://quality.embarcadero.com/browse/RSP-42144 Thanks

Regarding the above code edit. I decided it was better to just comment out that whole part and just leave the following since I don't want the menu to ever interact with the Alt key. Result := DefWindowProc(hwnd, uMsg, wParam, lParam);

Many thanks again. That has solved a few of the issues. However, the scale issue is now on my other screen. The issue is that I have 2 monitors set to different scales. Your GetScreenScale function always returns the scale of the main screen, not the screen that the active form is on. I do have a better solution now though, after seeking support from Embarcadero. The solution prevents the Alt key being processed while the mouse button is down, but it does require editing a local copy of FMX.Platform.Win. Change the code in "function WndProc(hwnd: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;" for WM_SYSKEYUP to this: WM_SYSKEYUP: begin // Local Edit: Change to prevent Alt key being processed while left mouse button is down if ((wParam = VK_MENU) or (wParam = VK_F10)) and not (PlatformWin.FormInfo[LForm].WasLeftMouseButtonPressed) then begin LForm.EnterMenuLoop; Result := 0; end else Result := DefWindowProc(hwnd, uMsg, wParam, lParam); end; I'm happy to make this change. I will report the bug in the Quality portal so that it hopefully gets fixed in future.

Many thanks. That does work and it also works when the Alt key is pressed down before the mouse. However, there is a small issue on my screen that has scale set to 125% in display settings. My guess is that the click on the caption bar isn't working in that case. That may be a quick fix to take the screen scale into account. That part may cause other issues though. For example, if the window is set to border style none or transparent mode then there is no caption bar to click. Also I wonder how I would get this to work on a second form that isn't the main form.

Something else I noticed. A breakpoint in TCommonCustomForm.KeyUp is never reached for the Alt key even though a breakpoint in TCommonCustomForm.KeyDown is. For all other keys on the keyboard that I tried, both were reached (even the Alt Gr key). Why is that?

Thanks for trying. Accelerator keys using the Alt key are a Windows thing, so I had suspected that this may only be a Windows issue. I also traced the code in FMX.Forms that appears to handle accelerator keys, but temporarily commenting it out didn't solve the issue. I also wondered if this interface could be used to somehow unregister the menu from using the Alt key, but couldn't see how. https://docwiki.embarcadero.com/Libraries/Alexandria/en/FMX.AcceleratorKey.IFMXAcceleratorKeyRegistryService.UnregisterReceiver

I found a post of yours where you discussed a method to prevent a beep and also disable accelerator keys by editing FMX.Platform.Win. I've tried this but it doesn't work and the whole application locks up. I used a TTimer to set the flag back to false, but it never gets called. Did you use some other kind of timer perhaps?

It's because of accelerator keys. Pressing Alt is normally used in Windows to select menu items. Alt+F will select File for example. This was also an issue for me in VCL, but as I said above, I solved that issue by resetting the key in the KeyDown event. There is a bug in FMX that means that these accelerator keys don't work. The reason this issue is so infuriating is that the thing that's causing the conflict doesn't even work! I've encountered many bugs in FMX while porting my application from VCL. In almost all cases I've found a solution, sometimes by overriding methods or in one case using a hack to write to a protected variable. I'm still confident that I may be able to find a solution for this issue.

The mouse up event is not triggered after the Alt key is pressed down, so the mouse gets stuck in a clicked down state after release. So there can be no completion event. That's the issue.

The main reason I use TMenuBar is because I have 2 forms with 2 different menus, and you can only have 1 TMainMenu in an application. The Alt+drag also needs to work on both forms. Also I had an issue with styles in TMainMenu, which I discussed here. I have seen people suggest to use a single TMainMenu and change the contents when the user changes active form, but this seems inefficient to me, especially as I don't think TMainMenu has a BeginUpdate method to prevent repainting while updating. Both menus contain a lot of items. The issue with styles would still be an issue anyway. I wonder if I can inherit a new class from TMenuBar and override some functionality to prevent the Alt key issue? Is a TMenuBar created by the Windows OS or is it created entirely by the application?

Actually, you can see in my demo that it also happens when you press Alt before mouse down. The issue happens whenever the user releases Alt before the mouse, regardless of which is pressed down first. The issue then happens a lot because users will typically release both at around the same time when they finish dragging.