BuyLog In
Bug Report T319524
Visible to All Users

After GridControl's context menu is closed, focus is moved to another GridControl

created 9 years ago

Hi,

I have a setup with a RibbonControl and two GridControls. The ribbon contains a delete button whose command is binded using a complex binding path to the appropriate command in the view model of the focused GridControl. Both GridControls have a context menu containing a delete button. All three delete buttons are defined using BarButtomItemLinks which point to a single BarButtonItem defined in a BarManager.

When the first grid has focus and a right click is performed on an element in the second grid to perform a delete operation sometimes the command for the first grid is executed. This behavior occurs also for the ribbon button when first grid is focused, right click is performed in the second grid and then the ribbon button is pressed.

I monitored the focus changes with Snoop and it looks like the first grid gets the focus sometimes back when the context menu closes. I would assume that the second grid gets focus on the right click and keeps it when context menu closes. Is this a bug or behavior from the framework itself? Do you have an idea for a workaround?

I have attached a sample project to reproduce this behavior. The archive contains only a screen capture which demonstrates the behavior when using the ribbon button.

Thanks,
Artur

Comments (2)
DevExpress Support Team 9 years ago

    Hi Artur,
    It appears the attachment does not contain any file. Please make sure you successfully attach the archive. We look forward to receiving it from you so we can research the issue on our side.

    Regards,
    Nadya

    AL AL
    Artur Lipinski 9 years ago

      Hopefully it works this time.
      Regards,
      Artur

      Sign in to comment on this post

      Answers approved by DevExpress Support

      created 9 years ago

      We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

      Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

        Sign in to comment on this post
        created 9 years ago

        Hi Artur,
        GridControl is a complex control containing a number of visual elements to represent columns, rows, cells, menus, etc. Therefore, the GotFocus and LostFocus events cannot be used to precisely determine whether or not TableView gets focused when a user clicks an inner visual element, presses a key, or invokes a menu.
        I think a more appropriate way of accomplishing this task is to handle the TableView.PreviewMouseDown event within FocusBehavior. Please check the attached modified sample demonstrating this approach and let me know if it helps.

        Thanks,
        Ilya

          Comments (2)
          AL AL
          Artur Lipinski 9 years ago

            Hi Ilya,
            Your suggested solution works for this use case, but might fail on others. We used the focus events to have a generic solution. Independent from our use case, we think that this strange behavior is a bug. Before the context menu opens, the clicked row gets the focus for a short time. When the menu closes (e.g. ESC is pressed) I assume as a user that the row should get the focus back, but instead sometimes the other grid gets the focus.
            We have the requirement for full keyboard support. When user switches with the keyboard to the other view and uses the menu key (which does not work, when RowCellMenuCustomizations are used (https://www.devexpress.com/Support/Center/Question/Details/T283311)) to open the context menu and decides to close it using ESC key, the focus should remain on the row. Because of the other issue we are not sure if this use case will work or not. We assume that it will not work, because the problem occurs when opening menu with mouse and closing with ESC.
            It would be great if this behavior could be fixed in the component itself.
            Thanks,
            Artur

            Kirill (DevExpress Support) 9 years ago

              Hello,
              We've discussed this issue and forwarded it to our R&D team for further research. Please follow our notifications to be informed about our progress.

              Thanks,
              Kirill

              Sign in to comment on this post

              Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

              Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.