Disabled and hidden objects able to receive focus

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Disabled and hidden objects able to receive focus

    I am creating dialogs with various widgets and injecting GUI_KEY_TAB/GUI_KEY_BACKTAB key presses to cycle focus through the widgets. If a dialog is created with hidden and/or disabled widgets, then these widgets can still accept focus, leading to some very strange behaviour. For example, try creating a DROPDOWN widget, call WM_HideWindow() on it and inject GUI_KEY_SPACE when it has focus. A disembodied LISTBOX appears where the hidden DROPDOWN would be displayed. How do I stop this unwanted behaviour?

    Regards,

    Craig

  • Hello Adrian,

    Apologies, I should have been clearer. The example I gave in the original post of the DROPDOWN widget does have both WM_DisableWindow() and WM_HideWindow() called passing the widget handle. Still it is able to receive focus and keyboard events.

    Is there anyway to stop focus passing to such objects?

    Regards,

    Craig

  • Dear Craig,

    if your need is that of moving the focus from a window to another from my limited experience I can suggest you to explicitly set the (new) focus using the function

    void WM_SetFocus(WM_HWIN hWin)

    provided that in the newly focussed window there is a widget that is able to receive the focus.

    Otherwise the window is not focussable.

    Best regards,
    Ezio

  • Dear Ezio,

    Thanks for the reply. I am currently evaluating emWin for use in an embedded application that will use a number of keys (probably 9 in total). The aim is to provide dynamic information and configuration windows. The evaluation project creates a dialog window with a number of widgets for data entry. Depending on current configuration or options selected on the form, some widgets may be hidden. The widgets are navigated by the user using the keys. By injecting GUI_KEY_TAB/GUI_KEY_BACKTAB key presses the user is able to cycle focus through the widgets. The problem I am having is that widgets that have been hidden using WM_HideWindow() and WM_DisableWindow() are still able to accept focus. It appears to the user that the focus disappears when in fact a hidden & disabled widget has it. The issue gets worse when a hidden/disabled DROPDOWN widget gets the focus, as if the user presses the GUI_KEY_SPACE key, then a "disembodied" list box appears!

    Is this expected or a bug? It would appear to me to be unwanted behaviour.

    Could the Segger developers (Adrian?) that frequent the forum offer a view?

    Thanks,

    Craig

  • And why don't you delete the un-needed widgets instead of hide them?

    In the application I am working I have a similar kind of framework: there are windows that have to be present or absent depending on some configuration flags but these flags are known only at run time, some of them are to be read from a flash, some other are communicated by another hw module so I don't know 'a priori' what windows/widgets I need and what I do not.

    So when they are needed I create them, when they are not I delete them, using respectively

    hWin = GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), _cbDialog, WM_HBKWIN, 0, 0);


    and


    if(hWin)
    WM_DeleteWindow(hWin);
    hWin=0;

    Nevertheless I had some troubles of focussability, cause there are situations where more windows/widgets are present at the same time and I solved them using WM_SetFocus as per my previous post.

    BR,
    Ezio

  • The widgets that are hidden are not unwanted. Depending on user interaction I need to show/hide widgets on-the-fly. I could create and delete the widgets as needed, but the overhead and maintainability of the project would be negatively impacted. I have considered this as a work-around.

    I guess my question is why are hidden and disabled widgets able to receive focus? Is this really by design, or something that should be addressed with the library?

    Regards,

    Craig