Hi,
I would like to know if an item is added / removed from a ListView.
How do I do this?
Thanks in advance
Printable View
Hi,
I would like to know if an item is added / removed from a ListView.
How do I do this?
Thanks in advance
It's your code... how would you NOT know if something is added or removed?
I'm confused. It's possible I just haven't had enough coffee yet. And given the number of times I just had to backspace to spell correct this post should be an indication of how much coffee I'm missing. yikes!
-tg
Sorry I didn’t explain myself properly.
What I meant is there is no event for item added and item removed.
I would like something like TextBox.TextChanged
Is that possible?
No, your question was quite clear... no, there isn't an ItemAdded, or ItemRemoved event... why would there need to be? That's what I was wondering, because it's not like things will show up (or disappear) magically from the ListView... it's your code... you should know when something is being added or removed because wrote the code to add or remove. What is it you're after exactly here? what's the end game?
-tg
Thank you for your reply.
You are right.
The reason why I would like the items added / removed is because when it happens a column may need to be resized.
For that I have a function, but the add item is done in a thread and a call to my function results in a Cross thread operation. Ehm … it’s a little difficult to explain.
And that's what I thought... there's an underlying issue here, and rather than understand the issue, you're using a sledgehammer approach.
You shouldn't be adding items in a thread... you can create the items... put them into an array or a list... and then when your thread is done, pass the array/list back... Then once you are back on the MAIN thread, you can then update your UI by adding the items to the list view. The UI should never be updated except from the main thread. Ever. Period. End of story. That's why you get the cross thread exception... you are attempting to do somethign to manipulate teh UI from a second thread. It's like trying to turn on the stove at home while you're at the office. Doesn't quite work that way.
There's two ways to handle it. One is to simply wait until you get home before turning on the oven. This is the mthod I mentioned initially. Let the thread create the items, queue them up into a list, then once you're done (you get home) then you add the items to the list view (turn on the oven).
The second way is to invoke the main thread ... you first check to see if .InvokeRequired (check if you're at the office) on the ListView ... and if so (yep, you're still at the office) you then you use .Invoke to launch a method that can then add the items (use your cell phone to run an app that then turns on the oven for you - you are, after all a geek and have the whole house wired, right?).
Personally I go with the list and add them all in one shot... but that's because it seems easier than trying to invoke at every add... if it was just a couple of updates, that would be one thing, but this sounds like it would be in somekind of loop, which means it's easier to jsut create every thing off in the thread, pass it all back, then add it when done... then you can go through it and dtermine if the list view columns need to be resized or not.
-tg
Hi again,
Thank you very much for your detailed explanation
Actually I am invoking (InvokeRequired) the main thread, but I see your point and will use a list instead.
This way it is much easier to handle the items added issue.
Thanks again,
Henrik
I think it's a little goofy there isn't an event to let you know when items are added. But there's not, so you have to be in charge of that yourself.
I think this is because having an event for that is for decoupling your code, it means that you can let things that could be on other forms know when a new item is added to the ListView. By not allowing that notification, the designers of ListView are asserting that your code to respond to an add/remove should be local to the actual Add()/Remove() calls. There's a little bit of philosophical back and forth that could be had there, but we're stuck with the interface we have so it's moot for this thread.
I think the right thing to do is as you sort of deduced: ListView usually represents some other in-memory list of items. You can, if you choose the right types, use a data structure that notifies you when it changes. That way, your column sizing logic is also affiliated with your logic to add new items, while you still have the decoupling benefits of separating your data structure from your UI structure.
I still don't see why such an event would be necessary... at least from the LV point of view... it's not like there are outside forces that load the file... which means you (as the developer) had to write code to .Add to the LV ... so if something else at that point needs to be notified, then you raise an event... but the LV itself... I don't think really cares. To me it doesn't make sense for the control to report an event that you just programmed. Now if the control allowed for the end user themselves to add stuff to it - like a data grid does - then, yeah, I could see value in it. But for something that is completely within the developer's control.... eeeehh....
-tg
It's a matter of decoupling, and the difference between these three codebases in pseudocode:
Quote:
"When an item is added or removed, recalculate the column's width."
Or its most common cousin:Quote:
On this form, for this ListView, if you call Items.Add() or Items.Remove(), please remember to call RecalculateColumnWidths().
One has the impact of saying, "No matter how or who does this, I want this to happen in response." That's far more powerful than having to remember to write code or call methods.Quote:
When this button is clicked, gather data from the database, create a ListViewItem, add it to the ListView, then recalculate the column's width.
When this button is clicked, gather data from controls, create a ListViewItem, add it to the ListView, then recalculate the column's width.
When this button is clicked...
Personally, when I find myself in these case, I'm going to create a method that adds (or removoves) and calls the resize... then I just call that method. Maybe I've been lucky with my use of the ListView control, but I've never run into a case where I'm adding or removing items from more than one, maybe two at most, locations... and if I do, I refactor the code into a method, and use that where I need to. Plus I'm not sure I'd want the event to fire off a fews hundred times, potentially reesizing after each, as I loop through a datatable... that just seems insane... it's a waste (in my opinion)... get the items, add to the LV, THEN resize the cols, once.
Maybe it's a philosophical issue, I don't know. Control events are typically based on user interaction. click, textchanged, resize, gotfocus, etc... the fact that a listviewitem was added to some listview isn't user interaction. meh.
-tg
It's kind of nasty shrapnel from a bad decision in WinForms design that only seems bad after using WPF.
In WPF, there isn't really a ListViewItemCollection, or there is but no one uses it. That's because if a ListView is to display customer data, you have your own list of Customers, and you describe what the UI for a single Customer looks like, and WPF does the work of displaying all those Customer instances in a ListView. Your data structure is almost always an ObservableCollection that implements INotifyCollectionChanged, because that's how the control knows when to add or remove some UI. Performance is helped by INotifyCollectionChanged coming with an idea of "batches". If you use it right, you can add 1,000 items and remove 400 with the end result being a single event that indicates all 1,000 new items and all 400 removed items.
In Windows Forms, control's different. You have to create a UI object that describes how to display a Customer for every Customer, then give that item to the ListView. Even if you have your own list of Customers, there's also a list of ListViewItems in memory that you have to simultaneously manage. For a lot of applications, it's worth the somewhat jankier architecture of letting ListViewItemCollection be your Customer data structure. I know how to do it well, and like any rough patch of code it's not hard to velcro something soft on top.
But now that I've seen greener pastures, I can't shake that I think it stinks a little.