Userarea keyboard focus issues in 2025.3

ECHekman

There seems to have been a change to userarea default behavior in 2025.3 - however i cannot find this in the release notes.
Mouse clicks still trigger GeUserArea::InputEvent, however keyboard and scroll events no longer work with default settings.
I found that when i explicitly set USERAREAFLAGS::HANDLEFOCUS in the AttachUserArea it will work like it did in previous versions. However USERAREAFLAGS settings are poorly documented and i cannot find what the settings do or if i need them (HANDLEFOCUS, TABSTOP, SYNCMESSAGE)

ferdinand

Hey @ECHekman,

Thank you for reaching out to us and reporting the issue. Please follow our support procedures for reporting bugs and crashes in the future. But I can confirm that there happened a regression. That is all I can say for now, as I haven't investigated deeper yet (for example, if using GeUserArea::Message helps).

I moved this into bugs, we are investigating.

Cheers,
Ferdinand

ITEM#600193 GeUserArea is drawn delayed and does not respond to all input events anymore

GeUserArea is drawn delayed and does not forward all input events to GeUserArea::InputEvent aynmore.

OK: 2025.2.1
NOK: 2025.3.1

Reproduction:

Run the attached code
Click the red square
Type on your keyboard with the dialog focused

Result:

The user area is drawn with a delay
Keyboard inputs are not handled anymore.
Adding the UA attachment flag HANDLEFOCUS will fix the non-forwarded keyboard input events but not the draw lag.

Code

import c4d

class MyUserArea(c4d.gui.GeUserArea):

    def DrawMsg(self, x1: int, y1: int, x2: int, y2: int, msg: c4d.BaseContainer) -> bool:
        self.DrawSetPen(c4d.Vector(1, 0, 0))
        self.DrawRectangle(x1, y1, x2, y2) 
    
    def GetMinSize(self):
        return (250, 250)
    
    def InputEvent(self, msg: c4d.BaseContainer) -> bool:
        print(f"{msg.GetId() = }")
        return True

class MyDialog(c4d.gui.GeDialog):
    ID_USER_AREA = 1000

    def __init__(self):
        self._ua: MyUserArea = MyUserArea()

    def CreateLayout(self):
        self.SetTitle("Blah")
        self.AddUserArea(self.ID_USER_AREA, c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT, 0, 0)
        self.AttachUserArea(self._ua, self.ID_USER_AREA) # c4d.USERAREAFLAGS_HANDLEFOCUS
        return True
    
if __name__ == '__main__':
    dlg = MyDialog()
    dlg.Open(c4d.DLG_TYPE_ASYNC, 0, -1, -1, 400, 400)

ECHekman

Thank you Ferdinand. Ill try to remember to post bugs to the bug subforum.

ferdinand

Yeah, no worries, only what matters is the form, what really helps us is the repro steps and code example thing. But users cannot post directly into the Bugs forum, only we can move things there. We do this so that this forum remains a clean list of actual issues and is not polluted by topics which turned out not to be bugs. So, you did nothing wrong in that regard.

We are currently cooking on a solution, I will probably communicate the outcome tomorrow.

Cheers,
Ferdinand

ferdinand

Hey @ECHekman,

you can find our general answer here.

This is unfortunately an unintended regression caused by an intentional bugfix, not taking API stability into account. The flag USERAREAFLAGS::HANDLEFOCUS is meant to signal if a user area is focusable or not. But before user areas were always focusable, as this flag was erroneously being ignored.

We then 'fixed' this, causing the chain of events. The in detail logic is then that some types of events are not possible for non-focusable gadgets, as for example keyboard events. I will touch up the docs a bit in that area, as things are indeed a bit thin there. But the doc changes will probably not make it into the next release, given how close it is, unless I patch them in there manually.

So, long story short, compiling with USERAREAFLAGS::HANDLEFOCUS against the 2025.0.0 SDK will result in a binary that will be compatible with all versions of 2025, you did the right thing.

Cheers,
Ferdinand