Mouse handling with ForceCaptureInput to an edit?

I am fleshing out the edit capabilities of my behavior tree view. I have it so that it turns on a TCastleEdit if you click on the label, so you can edit the name of the node. I found the default behavior difficult as it couldn’t hold focus if you even moved the mouse at all away from the control even with EditorSelectOnHover disabled. The (overkill) solution was to set ForceCaptureInput to that edit so it would get all keypresses while active.

But if I ignore the mouse clicks (handled := false), they go to controls underneath causing trouble. If I don’t ignore the mouse then it is trapped to the control and can do nothing else. I close the control when Enter or Esc pressed. I also want to close it if the mouse clicks anywhere outside of the edit. But then no matter what you click on the Sender is the edit because of ForceCaptureInput. The event mouse coordinates appear to be screen based, but the control is well down in a tree of controls and unclear how to check if that screen position is in our out. Maybe there is a more elegant way to control focus? (like turning off the mousefocus, or just taking keyboard events with the forcecaptureinput). Suggestions?

I just make it so any mouse clicks close the edit, it works great. I also now have link lines working using little shapes.

This is a known limitation of current TCastleEdit: It doesn’t hold “persistent” focus. Using ForceCaptureInput to force receiving all keys is indeed our recommended solution, for now. It indeed brings other problems, since then the control listed on ForceCaptureInput gets all input first, regardless of it’s position (X, Y, depth).

So, no better recommendation about this I’m afraid, the workaround you describe is just what one has to do, for now.

It’s part of the roadmap: Roadmap | Manual | Castle Game Engine , " 45. Improve editing (TCastleEdit, planned TCastleMemo)".

1 Like