@BenJule I had a working (fully tested) and more complete fix in #10619 but it got rejected in favor of the in-house version, which I didn't think much of (and maybe wasn't fully tested). What a mess, for one shortcut. 🤷🏼

@mpaperno Thanks for the feedback! I completely understand where you're coming from, and it’s definitely frustrating when working community code gets sidelined.

The main reason I opened this PR (#10826) is that the recent in-house fix was a bit too rigid for certain UI states. Under Windows, when dealing with custom composite panels (like the TextInput panels), the OS focus can get trapped on the outer container rather than landing directly on the inner text control.

Checking strictly for a direct wxTextCtrl focus breaks in these specific scenarios because the parent container isn't recognized as an active text entry field, which is why the shortcut still intercepted the 'Z' key.

By switching to wxTextEntry and traversing both up the parent chain and down through the direct children (GetChildren()), this fix ensures that even if Windows lands the focus on the outer wrapper of a composite widget, the app still safely realizes that a text input is active.

Hopefully, this covers all the edge cases this time around so we can finally put this shortcut issue to rest!

Hi Ben, thanks for the detailed explanation!

Could you give me a specific example of what you're describing, in terms of reproducing steps in the UI? I thought I tested every permutation, but I guess not!

Thanks,
-Max

Sure thing, Max! The issue primarily shows up on Windows when interacting with custom composite fields where the focus lands on the outer container rather than the inner native wxTextCtrl.

Here are two easy ways to reproduce it in the current UI:

Scenario 1: Filament Calibration Tab

1. Open the Calibration tab.
2. Click on a filament name input field to edit it.
3. Type any name or value containing the letter 'z' or 'Z'.
4. Result: Instead of typing the character, the viewport triggers the global "zoom to fit" shortcut, throwing your camera view off.

Scenario 2: Object Manipulator Panel (Right-hand Sidebar)

1. Add a primitive shape (like a Cylinder) to the bed.
2. Select the object and click on the input fields for Size or Position in the right-hand panel (specifically the Z-axis field).
3. Try to type a decimal value or change the number using the 'Z' key, or use a name field if editing object/part names.
4. Result: The focus gets trapped on the custom text wrapper panel. Pressing 'Z' immediately triggers the canvas zoom instead of entering the character into the field.

Since wxWindow::FindFocus() returns the composite wrapper panel on Windows in these states, the old strict wxTextCtrl check evaluates to false, letting the top-level CHAR_HOOK steal the keystroke.

Thanks Ben,

Yea, if I understand you correctly, I can't reproduce your examples when using the fix I originally proposed. I haven't tried the current master code. I guess this is somewhat academic at this point, but I'd be curious if you have tried that, or could, to see if you get different behavior.

On "scenario 2" maybe I don't understand... Are you referring to editing the numeric fields in the Move and Scale tools? The ImGui ones? (Or is there some other sidebar?) With my original wants_keyboard() check, I get no reaction when pressing z if any of the editable fields have focus (expect input). When those fields aren't focused then the view does change, which is intentional, just like the CTRL + 0-7 shortcuts do.

And editing object names (in the tree view, if that's what you mean) was also an example I mentioned specifically in my PR. As well as other fields in the sidebar.

I think you already noticed, but my version was using wxTextCtrl, not wxTextEntry at all, which didn't seem to require any recursions. I don't understand why the latter was used in the first place.

Anyway, thanks again!
-Max

You're totally right, Max! If Bambu Lab had merged your original PR (#10619) in the first place, we probably wouldn't even be having this academic discussion right now. Your want_keyboard() check for ImGui and the strict wxTextCtrl approach was solid for the codebase back then.

The mess started because the in-house version that actually made it into master shifted towards using wxTextEntry and introduced the rigid focus-checking logic that broke things for Windows users. Since my PR (#10826) is directly hotfixing their broken implementation in the current master, I had to work with what's there.

To clarify Scenario 2:
You are correct that the on-screen popups for Move/Scale tools rely on ImGui. However, I was referring to the native right-hand sidebar panel (the Object Manipulator/Global settings wrapper). On Windows, when you click into those numeric fields, wxWindow::FindFocus() returns the custom composite panel holding the input, rather than the underlying text control itself.

Because Bambu's current master code only checks the top level of that focused window, it completely misses the fact that a text field is active inside it. That's why the recursion (GetParent / GetChildren) combined with wxTextEntry became necessary in my fix—it forces the app to look inside that custom wrapper panel and find the actual text interface.

I haven't re-tested your exact original branch against the absolute latest master commits, but the main goal here was just to clean up the gaps left by the official in-house patch so Windows users can finally type a 'Z' again without the viewport flying away!

Thanks for the great technical exchange, highly appreciate your insights on this!