Mike Warren

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?

I'd love to know if there is a workaround too. My program is still in development, but I cannot release it with such a bug. That would be very unprofessional behavior. I go to a lot of trouble to make my applications as bug free as possible. If this is not fixed by the time I get close to release I will need to find a workaround myself.

I'm having a couple of problems with dragging objects inside a scrollbox. My actual use case is a lot more complicated, but I've created a simple test case (attached) to demonstrate the problems. 1/ When the items inside the scrollbox are scaled larger the scrollbars do not update, making it impossible to scroll to the edges of the component. I can't find any method to update the scrollbars. 2/ When any components are scaled below 1, the components will no longer properly follow the mouse when dragged. Instead, the component being dragged will jump all over the place. This problem gets particularly bad as the scale decreases, especially below 0.5. Am I doing something wrong? If not, does anyone have workarounds? Here's a video showing the problem: Test.zip

Ah! I see. My mistake was changing the scale of the ScaledLayout. It looks like the scaling happens automatically when the size is changed. Of course, the correct answer was in your first reply. I just had scaling in my head and thought that was what you meant when you said "when you work with the TrackBar change the size of the Layout appropriately" I misinterpreted that as changing the "scale", not size.

Brilliant! That seems to fix everything. Now I just need to properly understand it. 🙂 Thank you very much!

Because that's the only way I've found to stop it bouncing all over the place when the scale is below 0.5.

I'm actually having quite a bit of trouble solving part 1 of my problem. Attached is a new version of my test program. In this version a border is drawn around ScaledLayout1.OriginalWidth and OriginalHeight in black and a green border is drawn around ScaledLayout1.Width and Height. The green border tracks the scaled size nicely, but the black one becomes smaller when Scale > 1 and larger when the Scale is < 1. The black boarder (OriginalWidth/OriginalHeight) the determines what the scrollbars do. I've tried all sorts of things and keep going around in circles. Test2.zip

Thanks for your reply. I think you've given me the clue I was looking for in order to progress on this. Unfortunately, your first idea of resizing the components rather than scaling them doesn't appear to be realistic in my case. In the real program I have dozens of components including images, paths, text etc and it would be quite a task to keep everything including line thicknesses, fonts etc properly scaled and aligned. On the other hand, scaling the main container component takes care of all that for me. However, it does look like Layouts will be at least part of the answer. I had not looked into layouts before now, so don't have an understanding of them. I found the Embarcadero documentation on layouts, but still don't have a proper grasp on them. As an experiment, I added a TScaledLayout to my ScrollBox in the test app. Then I moved the blue rectangle to inside the Layout. Now, scaling works beautifully insofar as everything moves nicely when dragged with the mouse, no matter what the scale, but the Scrollbars on the ScrollBox still do not adjust to the size of the scaled components inside. It's 3am here, so maybe it'll be clearer after I've had some sleep. Thanks again for pointing me in the right direction.