Some questions and issues surface regularly on the Forums or in emails. This section has several of the most common questions. Please read the questions before asking questions on the Forum. Several people have been known to have blood pressure problems.
Yes. Maybe. Depends.
Some of the tricks of the ObjectListView depend on manipulating the underlying Windows ListView control. Obviously, these tricks will not work on Mono.
However, the code should compile and run on Mono. You will need to define the conditional compilation symbol MONO in your project.
I have tested the ObjectListView under Ubuntu and it works as expected, albeit without some functionality. I have also tested it with the Windows version of Mono, and it still works, though it is not pretty. I have no access to a Mac or to other versions of Un*x, so I would be interested in hearing people's experiences on these operating systems.
Please don't ask me Mono questions. You will have to look elsewhere for Mono expertise.
The code on SourceForge is released under GPLv3. The GPL is a viral license, meaning that if you use some GPL-covered code in your application, your application must also be covered by GPL. This is generally not what commercial developers want. (I am not a lawyer. This is not legal advice. It could be completely wrong).
However, if you wish to use this code in a commercial application, please contact me: email@example.com .
ObjectListView is a wrapper for the underlying ListView. It makes a ListView much easier to use, but it can't change the control's basic behaviour. One limitation of a ListView is it that cannot have rows of different heights. There is no way to make one row be taller than other rows. It's just not possible. So there is no way to word wrap a long line on just one row either.
If being able to have rows of different heights is essential to you, ObjectListView is not your solution. You may want to consider Matthew Hall's excellent XPTable and its update project, as well as Lee Paul Alexander's fantastic Outlook-style list.
If you are using Visual Studio, check under the Tools>>Options, in the Windows Form Designer category (turn on Advanced settings to see) for a setting "AutoToolboxPopulate." This should be set to True.
Also, make sure you have a Windows Forms project. ObjectListView is a Windows Forms control: it will not appear in the toolbox for a Windows Presentation Framework project, nor for a WebForms project.
This should work, but it doesn't.
In another well kept secret, the
ListView cannot handle checkboxes when in virtual mode (a
FastObjectListView uses virtual mode). MS's documentation doesn't say it doesn't work. It does say that checkboxes don't work in Tile view, but there is nothing about it not working on a virtual list. In fact, there is at least one Microsoft blog that suggest checkboxes do work, so long as you avoid the
CheckedItems property (see here).
But delving with Reflector shows that this is not true. For example, both the
CheckedIndicies properties work by running through all the items in the view and collecting those where
Checked is true. That strategy simply will not work on a virtual list.
As of v1.13 (July 2008), I have changed VirtualObjectListView (and this FastObjectListView) so it can support checkboxes.
Nothing. That's what it is supposed to do. The ObjectListView knows nothing about your model objects, and particularly it doesn't know when they have been changed. Only you know that. When you know that a model object has changed and needs to be updated, you can either call
RefreshObject(myModelObject) to update just one object, or you can call
BuildList() to rebuild everything at once.
All of this is assuming you aren't using a
DataListView should automatically update when you update the model objects.
"Thread-safe" is a notoriously slippery term.
If you mean, "Can I do whatever I like with an ObjectListView from various threads at the same time?" the answer is "Probably not."
If you mean "Can I update the ObjectListView from a background thread?" then the answer is, "Yes, so long as you stick to the primary commands." Specially, these methods can all be called from background threads, and the control will work as expected: