Hi,

Welcome to NvDA list.

Focus entered is most appropriate if an item inside a container (lists, for example) is focused.

Regarding focus item problem: the code fragment below won’t work simply because it’ll match ALL edit fields (think about what that if statement does, as it’ll silence all speech if system focus moves to any edit field). A common solution is to match a specific edit field by inspecting window class names, control ID’s and what not, along with properties of accessibility API object representing the edit field to screen readers (in this case, what Java Access Bridge says about the edit field in question).

Auto-completes and a more general solution: I think the best way to handle this situation is defining an overlay class. This means letting the app module come with an overlay class representing the edit field, with the overlay class dealing with focus announcement, auto-complete suggestions (there is already a behavior mix-in defined for it named EditableTextWithSuggestions) and others. Then in the app module class, you can use chooseNVDAObjectOverlayClasses method to locate the specific edit field represented by the overlay class and inserting that class to top of the classes list (clsList), which means any event NVDA listens to and commands will be sent to that edit field before falling back to default implementation.

Although users list may provide you with some starting points, it isn’t really a forum that talks about intricacies of add-on development; there is a sister forum to this users list (named nvda-addons hosted on Groups.IO) where people like you come together and share their knowledge.

P.S. I’m the one who wrote definitions for EditableTextWithSuggestions mix-in back in 2017 as part of a project to let NVDA deal with UIA search fields.

Cheers,

Joseph