Mike Warren

57 minutes ago, Nigel Thomas said:

Does this help?

https://stackoverflow.com/questions/14407759/delphi-xe3-mainform-hide

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.

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?

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.

15 hours ago, Vandrovnik said:

When importing settings using Migration Tool, there is a button "Version Migration", which probably should (must?) be used when upgrading from 11.3 to 12. At least I have used it and got no errors.

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.

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.

It doesn't appear to be fixed to me.

On 9/19/2023 at 5:07 AM, XylemFlow said:

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

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.

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;

2 hours ago, dwrbudr said:

How is your code supposed to work since you don't use at all the mouse position in the code?

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.

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?

Done.

On 8/16/2023 at 11:32 PM, XylemFlow said:

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.

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?

12 hours ago, XylemFlow said:

 However, there is a small issue on my screen that has scale set to 125% in display settings.

The new version attached should account for that.

Quote

For example, if the window is set to border style none or transparent mode then there is no caption bar to click.

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.

Quote

Also I wonder how I would get this to work on a second form that isn't the main form.

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.

On 8/9/2023 at 12:21 AM, XylemFlow said:

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 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.

Thank you all for your replies.

@XylemFlow: That is exactly what I was looking for! I learn so much better by example and your example is very close to what I want to do.

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?