Mike Warren

In the past all I needed to do was add Application.ShowMainForm := False, but FMX does not have ShowMainForm. Setting the main form's Visible property to False, either at design time, or in Form.Create does nothing, and adding MyForm.Visible := False to the application anywhere before Application.Run causes an A/V. I need this to work on Windows and Mac, so a WinAPI solution is not suitable. Does anyone have a suggestion?

Actually, that StackOverflow thread looks like it might contain the answer in the second reply. Overriding the CanShow method seems to stop the flash. function TForm1.CanShow: Boolean; begin Result := not Timer1.Enabled; end; procedure TForm1.Timer1Timer(Sender: TObject); begin Timer1.Enabled := False; Left := 500; Top := 200; Visible := True; end;

Thanks for the reply, Nigel. Unfortunately, the form flashes up briefly at the default position and size before being hidden. Below is something I just thought of. It seems to work fine on Windows. I'm not able to test on Mac at the moment. unit Unit1; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs; type TForm1 = class(TForm) Timer1: TTimer; procedure FormCreate(Sender: TObject); procedure Timer1Timer(Sender: TObject); private StartLeft: Integer; public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} procedure TForm1.FormCreate(Sender: TObject); begin StartLeft := Left; Left := MaxInt; Timer1.Interval := 4000; Timer1.Enabled := True; end; procedure TForm1.Timer1Timer(Sender: TObject); begin Timer1.Enabled := False; Left := StartLeft; end; end.

I just tried a FMX NumberBox in D11.3 and D12 and find it a complete mess. Nothing about the operation is intuitive. In addition to your observation, if I try to highlight the text by clicking and dragging, any vertical mouse movement at all changes the value wildly. Ctrl+A does not work for me. Personally, I'd do my own thing and forget TNumberBox completely.

That's what I used the first time where everything got messed up. I skipped it on the second installation and in the small amount of testing I've done the installation seems to have worked fine.

I've been using Delphi since 1996, but have been fixed at D7 for many years. I've finally upgraded to D11.3 and am creating my first FMX based application, targeting Win64 and Android64. I added an ActionList and added an Action with a shortcut of Alt+X. The problem I have is that the Alt+X key press triggers a windows beep sound. This is something I do regularly in VCL based apps. As soon as an action with a shortcut is defined the Windows beep does not fire. How do I fix this in a FMX based app?

Installing D12 was "fun" for me. I made the stupid mistake of trying to import settings from V11.3 and got dozens of errors during the install and each time I ran it. Tried uninstalling, and that took ages before finally locking up. Tried the uninstaller again, and got told it couldn't uninstall without telling me why. Fortunately, I run Delphi in a VM, so I just created a new duplicate of my working dev VM and installed it from there. Don't really understand why the "offline" installer spent most of its time downloading things, but finally it completed. One of the bugs that was causing me problems is fixed. Another has supposedly been fixed, but has not, and within the first 10 minutes I found a couple of new bugs. I'm looking forward to the first maintenance release.

This issue is mostly fixed in D12. Only tested on Windows so far. Accelerator keys work in TMainMenu and on TButton.Text without causing a Windows beep. Shortcuts using Alt+<letter> do not work in menus, but they do work in actions. Alt + the first letter of a root main menu item will open that menu and then the first letter of each sub-menu item will highlight it, but not select it. So even though this is not exactly the behaviour in VCL, at least it's workable.

I need to allow the users of my program to draw lines and curves. Is TPath the best way to do this? I haven't been able to find much in the way of documentation so far, and because this sort of thing is totally new to me I'd love an example to allow me to understand what needs to be done. Probably the way I imagine the user would interact would be to click a start point and then an end point to draw a line, and then click along the line and drag to create nodes to change the line into a curve. I'm expecting a steep learning curve, unless there is already a Firemonkey component I can purchase to do this. Can anyone offer any suggestions?

It doesn't appear to be fixed to me.

Looks like this bug has been fixed in D12 according to the QC. I haven't installed D12 yet to check.

A simplistic approach might be to use MouseDown and trigger a timer. In MouseUp reset the timer if it hasn't expired. I haven't put a lot of thought into this, but feel it should be possible to make it work.

I don't know what I'm doing wrong, but I can't seem to get this to work properly. For each page (TFrame) I have a TScrollBox that contains a number of Layers (TScaledLayout), which in turn contain a bunch of components. I zoom in and out using the mouse wheel and want the position of the frame to remain visually locked to the mouse cursor as I zoom. What I thought would work would be to change the Scrollbox.ViewportPosition as I zoom, but this produces a non-linear movement (a strange curve). Each step of the mouse wheel changes the zoom in 10% increments. Here's the code: if WheelDelta > 0 then begin Z := CurrentPage.Zoom + 0.1; if Z > 4 then Z := 4 else CurrentPage.sbView.ViewportPosition := CurrentPage.sbView.ViewportPosition * 1.1; end else begin Z := CurrentPage.Zoom - 0.1; if Z < 0.1 then Z := 0.1 else CurrentPage.sbView.ViewportPosition := CurrentPage.sbView.ViewportPosition / 1.1; end; CurrentPage.Zoom := Z; This is the Zoom code: procedure TfrmPage.SetZoom(const Value: Single); var I: Integer; begin FZoom := Value; for I := 0 to LayerCount -1 do Layers[I].Zoom := FZoom; end; // The layer frame is not shown. Instead, the ScaledLayouts are parented to the page frame's scrollbox procedure TfrmLayer.SetZoom(const Value: Single); begin FZoom := Value; slContent.Width := slContent.OriginalWidth * FZoom; slContent.Height := slContent.OriginalHeight * FZoom; end; The video below shows what happens. What am I doing wrong?

Okay, this seems to work: var P1, P2: TPointF; begin // Mouse location on page before zoom P1 := (sbView.ScreenToLocal(Screen.MousePos) + sbView.ViewportPosition) / CurrentPage.Zoom; if WheelDelta > 0 then begin Z := CurrentPage.Zoom + 0.1; if Z > 4 then Z := 4; end else begin Z := CurrentPage.Zoom - 0.1; if Z < 0.1 then Z := 0.1; end; // Mouse location on page after zoom P2 := (sbView.ScreenToLocal(Screen.MousePos) + sbView.ViewportPosition) / Z; sbView.ViewportPosition := sbView.ViewportPosition + ((P1 - P2) * Z); CurrentPage.Zoom := Z;

Good point. This is simplified because I couldn't get it to work in a way that makes sense to me. I have a member that gets set in the page's MouseMove event: FMouseOnPage: TPointF But I took that out for testing, expecting the zoom to at least stay centred. But It does that weird curve.

Done.

Excellent! If you do report it, post the link here and I'll vote for it.

Thank you both. I really appreciate your help. Sorry for the delay getting back to this thread. I've been sick and haven't had a chance to delve into this yet.

I've just started to look at this and have a problem already. I need to be able to edit these paths later which means I have to be able to click on them. The path is clickable, but it doesn't exactly follow the line. It's an area (shown in blue on the attached image. Ideally, I'd like to detect a click near the line (maybe 4 pixels either side and not the area the TPath exposes. At this point the only thing I can think of is going to require a lot of code to calculate where the line is, which will run way too slow to be practical in a mouse move event, especially when there may be 20 to 50 (or more) paths on the form. Does anyone have an idea on how I can achieve this?

The new version attached should account for that. I did think of this as a limitation, but figured it wouldn't be likely to be the case on a form that is using a menu bar. In that case the click would be on the first menu item. I thought about that last night. The new version uses Application.ActiveForm instead of Application.MainForm. This is very definitely a kludge. As I said previously, I've moved to using TMainMenu instead of TMenuBar. TMenuBarAltIssueMW2.zip

Here's a unit that seems to solve this for me. All you need to do is add MouseHelper to your form's uses clause. It creates a low priority thread that generates an extra MouseUp event if an Alt key was pressed while the left mouse button is down. TMenuBarAltIssueMW.zip Edit: I should mention I've done minimal testing at this stage. I really need to get back to my other work.

At this point I'm going to have to concede defeat. I couldn't even get TMessageManager to give me Windows messages. I traced it though FMX.Forms and FMX.Menus, but it seems that the Alt key triggering the menu happens somewhere else that I can't find.

I just tested your program on an ARM Mac and it seems to work fine. That means a solution only needs to be found for Windows.

It was a normal TTimer set to 1 second, IIRC. I don't have it on my form any more, but I do still have a backup of my copy of FMX.Platform.Win. Well, I just deleted a very long reply, including a new version of your test program because I thought I'd found a workaround, but it didn't really solve anything. What I have discovered, however, is that very early on, WM_LBUTTONUP messages are no longer handled if the Alt key is pressed and released while the mouse button is being held down. I'll keep investigating. I suspect this has something to do with the FMX Message Manager, which I currently know nothing about.

So many odd things with FireMonkey... I was forced to move to TMainMenu for the same reason. There have been several changes I've had to make to my application because I just couldn't get what I wanted without weird side effects. Have you put some thought into maybe redesigning the functionality that requires TMenuBar? Edit: Also, I couldn't get TMenuBar to play nicely with MacOS. Also also, even TMainMenu has a problem on MacOS that I haven't put any time into trying to solve yet. The Mac Menu doesn't show properly.