Mike Warren

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.

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.

Considering how long FireMonkey has been around, I'm really surprised by how much basic functionality is still missing. In a VCL app, if a mouse button is pressed and held within the form's client area, then the MouseUp will still fire, even if the mouse has been moved outside the form while the button was held down. This does not happen with a FMX application. If the MouseUp occurs anywhere except over the control that triggered the MouseDown, the MouseUp event it is ignored. Tested on Windows and Mac. I don't like my chances of Embarcadero fixing this any time soon, considering the Alt+Key problem was reported several years ago. Can anybody suggest a workaround?

Thanks for your reply Alexander. This looks very promising so far. I currently use AutoCapture to move controls within a frame in a TScrollBox (left click) and to move the frame itself within the scroll box (middle click). Unfortunately, the mouse up is lost if it is released outside the scrollbox or form. MouseCapture definitely overcomes this problem, but it clashes with AutoCapture, so I'll have to rethink what I'm doing. I think you've pointed me in the right direction.

I put a bit of time into this and found where the messages are being passed to Windows in FMX.Platform.Win. As a quick and dirty test I copied FMX.Platform.Win to my project source folder and made some modifications to it. 1/ I created a global variable I called SuppressWM_SYSCHAR. 2/ In my form's KeyDown event I checked if Alt plus a letter was being pressed, and if so, I set SuppressWM_SYSCHAR to true. 3/ At line 837 I check SuppressWM_SYSCHAR and if false I allowed DispatchMessage(Msg); to be called 4/ A timer set to 50mS in my form would reset the SuppressWM_SYSCHAR back to False I discovered that this also suppressed menu accelerator keys. I then compiled for MacOS and discovered that shortcuts using Alt+ also cause a system beep there. I also discovered that the Alt+ keys generate different message codes under MacOS. It was at this point that I decided to scrap the whole idea of using Alt+ keys for any shortcuts on button activation since these don't work on MacOS anyway. I changed any shortcuts to not use Alt+ alone. I feel defeated by this and just cannot afford to put any more time into trying to understand it.

Is it possible to make a child FMX component display behind the parent? SendToBack only affects its Z-order in relation to other siblings.

Thanks for the suggestion, but it's not what I'm after. Remy's solution is best for my situation.

That's what I'm going to have to do. It just means I'll have to manually move the TImage whenever the TRectangle is moved. Thanks.

Thanks for your reply Remy, I suspected that might be the case. Why do I want to do this? I have a component I create at runtime that's inherited from TRectangle. One of the additions is that I have a TImage to create an associated "icon" that sits next to the rectangle. These 2 items are normally moved together, but can be moved independently by holding the control key down. If the user decided to overlap these 2 components, then showing the complete rectangle is more desirable. I can't make the parent the image, because that will sometimes be hidden, which would hide the rectangle, which must always be visible.

How do I access the InplaceEditor of a TStringGrid? Specifically, I'll like to respond to KeyDown and KeyUp. The first task I need is to convert every entered character to uppercase, but I expect to need to do more later.

That's what I'm doing.

Except that in FMX: [dcc32 Error] uAPMain.pas(1103): E2003 Undeclared identifier: 'ecUpperCase'

Thanks for the ideas. I decided to go with the custom editor because for other cells I need different types of editing.

That's a great idea. Thanks.

No, it doesn't.

Unfortunately, I want to show this as the user types.

No problem. Thanks anyway.

Thanks for the reply Lars. Am I mistaken that I can't find OnSetEditText in FireMonkey? It seems to be VCL only.

Also, my report was closed as it's considered a duplicate. Please vote on https://quality.embarcadero.com/browse/RSP-33860 I see this was reported as far back as 10.3. I really don't understand how almost every Delphi FMX developer is not being caught by this. Do Delphi developers just accept unprofessional behavior from their applications?