Mouse events not triggered, caused by styled TMainMenu?

[XylemFlow 6]

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

Edited July 29, 2023 by XylemFlow

[Alexander Halser 20]

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? 

 

Edited August 23, 2023 by Alexander Halser

[Serge_G 85]

Hi,

I think there are more than one coding errors 🙄
i.e. ChildForm is not released, StyleBookLight don't contain data ....

 

I worked a similar project last year, you can find here

7 hours ago, Alexander Halser said:

So I loaded my own dark skin into your dark stylebook.

Guess what? Works like a charm,

I had some similar problem using an old 10.2 style (don't remember circumstance) 
 

[Alexander Halser 20]

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.

[Serge_G 85]

1 hour ago, Alexander Halser said:

Where do you see a problem here?

Sorry for that, I saw that form2 was created once. I am not adept of that, preferring a modalform.Create and modalform.release in my apps

 

1 hour ago, Alexander Halser said:

StyleBookLight is not required to produce the problem.

Yes, but it's a lot perturbing for me

To answer this usage of old style usage

 

1 hour ago, Serge_G said:

(don't remember circumstance) 

retrieve my mind's ticket is here (Patrick Premartin is the reporter because I was lazy to do it )

french discussion here

 

@XylemFlow

procedure TForm1.CheckBox1Change(Sender: TObject);
begin
  if CheckBox1.IsChecked then StyleBook:=StyleBookDark
                         else Stylebook:=StyleBookLight;
    UpdateStyleBook;
end;

procedure TForm1.MenuItem4Click(Sender: TObject);

begin
  // Apply current style to modalform 
   Form2.StyleBook:=Stylebook;
   Form2.Showmodal
end;

tested with polardark_win and polarlight_win styles

Edited August 23, 2023 by Serge_G
suggestions

[Alexander Halser 20]

 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 

[Serge_G 85]

I have no response to that, all my "pro" FMX applications (using at least 2 styles)  are D10.3 with few chance to update to newer versions.

Retiring at the end of the year, I don't think I should face the problem