none
Selected Item lost in ListView controls RRS feed

  • Question

  • Greeting folks,

     

    I was wondering if anyone can help with this, unless I'm doing something wrong, there seems to be a bug with the ListView control.

     

    The situation is this; I have an MDI app. that consists of an MDI Child form containing a ListView control.

    A context menu pops up when the user right-clicks on any item in the ListView. If the user clicks on the menu item a new MDI Child form will appear, allowing the user to edit the selected ListView item then, when the user has finished editing, the 'edit' form will disappear and the original form will reappear with the original ListView item still selected.

     

    The problem I'm getting is that the selected ListView item is no longer visibly selected when I return from the editing screen. I've set the HideSelection property on the ListView to 'false' but it has made no difference.

     

    I've tried 'disabling' the form instead of making it invisible and this works, the ListView item is still selected when the form is re-enabled.

     

    One thing I've noticed; I notify the first form that the 'edit' operation has finished via an event triggered by the 'edit' form. To give access to the selected ListViewItem I pass it to and retrieve it from the 'edit' form in the 'edit' form's Tag property and I've noticed that, upon return from the 'edit' form, the ListViewItem is perfectly normal until I set the original form's Visible property to 'true'. Then the ListViewItem's 'ListView' property gets set to null and its 'Index' property, which contained the correct index value, get set to -1.

     

    Has anyone got any ideas as to what's wrong?

     

    Many thanks

     

    RobDev

     

     

     

    Friday, April 25, 2008 12:28 PM

Answers

  • Your description isn't crystal-clear but you mentioning the Visible property is a red flag.  The Windows MDI implementation doesn't allow MDI child windows to hide themselves.  Windows Forms works around this limitation by completely destroying the MDI child and its controls when you set Visible = false.  And re-create them from scratch when you set the Visible property back to True.  That has side effects, losing the selection of a ListView could well be one of them.

    A workaround is to save the selected item in a member variable and re-select that item after setting Visible = true.
    Saturday, April 26, 2008 8:12 PM
    Moderator
  • Hi nobugz,

     

    sorry about the unclear description but I think you've answered the problem I'm getting perfectly. From what I've observed, the ListViewItem's ListView property appears to be intact until I set the Visible property of the MDIChild form back to 'true' (having previously set it to 'false'), whereupon it becomes null. This fits perfectly with your description of how Windows Forms destroys and recreates the MDIChild form from scratch. I couldn't find any reference to this process in the MSDN Library but there is an awful lot of info in it and maybe I just missed it.

     

    Many thanks for your very helpful reply, it's enabled me to proceed with my development.

     

    Thanks once again.

     

    RobDev

    Sunday, April 27, 2008 1:14 PM

All replies

  • Your description isn't crystal-clear but you mentioning the Visible property is a red flag.  The Windows MDI implementation doesn't allow MDI child windows to hide themselves.  Windows Forms works around this limitation by completely destroying the MDI child and its controls when you set Visible = false.  And re-create them from scratch when you set the Visible property back to True.  That has side effects, losing the selection of a ListView could well be one of them.

    A workaround is to save the selected item in a member variable and re-select that item after setting Visible = true.
    Saturday, April 26, 2008 8:12 PM
    Moderator
  • Hi nobugz,

     

    sorry about the unclear description but I think you've answered the problem I'm getting perfectly. From what I've observed, the ListViewItem's ListView property appears to be intact until I set the Visible property of the MDIChild form back to 'true' (having previously set it to 'false'), whereupon it becomes null. This fits perfectly with your description of how Windows Forms destroys and recreates the MDIChild form from scratch. I couldn't find any reference to this process in the MSDN Library but there is an awful lot of info in it and maybe I just missed it.

     

    Many thanks for your very helpful reply, it's enabled me to proceed with my development.

     

    Thanks once again.

     

    RobDev

    Sunday, April 27, 2008 1:14 PM
  • Alternatively, it sounds like a situation where the edit form could (or perhaps should) be displayed as a modal dialog, rather than as an MDI child.  You won't have to use any events or notifications in the tag properties about when editing is complete and you won't have to worry about anything changing on the main form.

     

    Simply pass the ListViewItem by reference to the edit form, let the user edit the item or cancel out of the dialog, and move on.  This has the added benefits from a usability and UI standpoint that the user can move the dialog to refer back to and see what is on the main form (without being able to edit it directly), and that this is the behaviour with which most users are familiar when editing things in this way.  This is how you edit settings, do printing, select colors, edit text styles and properties, etc.

    Sunday, April 27, 2008 6:50 PM
  • Hi JayStation3,

     

    thanks for replying. Your idea regarding the modal dialog isn't appropriate in my case, although it would work perfectly well. The modal dialog will bring the whole MDI app to a standstill and its one of the requirements of the app that the user can continue doing something else within the app while my 'edit' form is being displayed. It is only the 'edit' form and its logical 'parent' that must emulate the modal dialog relationship.

     

    Thanks once again,

     

    RobDev

     

    Monday, April 28, 2008 7:24 AM