Re: Updating only visible rows in WPF ListView - WPF Discussion Boards

Pankaj Chamria22-Feb-09 21:48

Pankaj Chamria

22-Feb-09 21:48

The processing is actually on a background thread. And the only work that the UI thread is doing is updating itself whenever the INotifyPropertyChanged event is fired for a property. I think with WPF such high frequency of updates is bound to be detrimental to performance. I made a prototype in windows forms and that worked much better under the same load.

One more intersting point I observed is that Virtualization is by default true in ListView. Hence making IsVirtualizing = true explicitly, did not have any impact.

After trying out many options I am now gonna make use of the good old Thread.Sleep() to add re-curring delays in milliseconds while updating columns of the ListView. Its not an ideal way but i cant figure out anything else Frown | :-(

Pankaj Chamria,
Software Programmer.

Kunal Chowdhury «IN»13-May-09 0:48

13-May-09 0:48

Hi,

I am also facing the same issue while populating the huge collection of data in an ObservableCollection & binding it to the UI.

Please help me in this case. If you have any code for this, please share that too.

Regards,
- K

Pete O'Hanlon13-May-09 1:35

13-May-09 1:35

If you're adding large amounts of data, then I would suggest that you consider my implementation of a custom observable collection here[^].

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Kunal Chowdhury «IN»13-May-09 1:45

13-May-09 1:45

Yes... I have seen your link.

But, my problem is like Pankaj. I am adding a huge range of data at the first time & then on every second I am modifying the list's item properties. There are more than 10 properties. FYI, I am not adding new items, just modifying the existing data.

Due to huge property change in every second, there seems a performance issue as I am binding the data to the UI as UserControls.

How can I achieve this? Please help me out. I am using WPF 3.5 SP1.

Pete O'Hanlon13-May-09 1:55

13-May-09 1:55

Right, so you're bulk loading data and then modifying the individual items in the list, which results in multiple property changed events being raised. As only a finite amount of these items are being displayed, the first thing I'd do is wrap things up using a Virtualizing StackPanel.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Kunal Chowdhury «IN»13-May-09 2:06

13-May-09 2:06

I am already using the Virtualizing StackPanel, which loads more than 200 UserControls & displays 100 among them at a time> Each UserControl consists of 10 Properties.

Is it require to use the Custom ObservableCollection?
Let me know... how I can increase the performance...
Share Code if you have one...

Pankaj Chamria13-May-09 22:22

Pankaj Chamria

13-May-09 22:22

You seem to be having the same issue as i was with large number of property changed events getting raised..
Here are a few things you can try:
1) Out of all the columns make sure you raise changed events for only those properties that are changing in value.
2) In case you can afford to render the changes once every 1-2 seconds then following the approach given in the below link will be very useful. It solved my performance and UI hanging problems.

Try this Link[^]

Let me know if this helps.

Pankaj Chamria,
Software Developer.

Kunal Chowdhury «IN»14-May-09 2:48

14-May-09 2:48

Pankaj Chamria wrote:
2) In case you can afford to render the changes once every 1-2 seconds then following the approach given in the below link will be very useful. It solved my performance and UI hanging problems.

Can you elaborate the solution (if possible, paste the code) as this is very tough to understand a big post from the link you mentioned. OMG | :OMG:

Please share the code to improve the performance for those huge data in the collection.
In my case, it is getting hanged, when it is changing the property values. Frown | :(

Please help. I am waiting for your reply.

Pete O'Hanlon14-May-09 4:57

14-May-09 4:57

You may want to take a look at what my friend Tamir came up with here[^].

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Kunal Chowdhury «IN»14-May-09 21:02

WPF, Delegates, The calling thread cannot access this object because a different thread owns it

14-May-09 21:02

Pankaj Chamria wrote:
1) Out of all the columns make sure you raise changed events for only those properties that are changing in value.

I am changing all the properties.

Pankaj Chamria wrote:
2) In case you can afford to render the changes once every 1-2 seconds then following the approach given in the below link will be very useful. It solved my performance and UI hanging problems.

Can you post your code for solving this problem?

frosty_4th16-Feb-09 16:00

frosty_4th

16-Feb-09 16:00

Help,

I'm at my wits end. I have been working for days trying to execute the simplest task. Here is the basics of my WPF project.

I have a main form.
I have a Dialog.
I have a class module that handles serial comm

When I receive data on the serial line, I want to launch the dialog. My main form has an instance of my dialog. My main form also contains an instance of my serial comm class. When instantiating my comm class I pass a delegate sub to be called when data arrives on the serial port. So far so good.

The sub gets called when data arrives on the port, but when I try to launch my dialog I get the message "The calling thread cannot access this object because a different thread owns it".

What am I missing here? I have tried instantiating the dialog within the serial comm module but get the error that the instantiation must happen from an STA thread.

I have been googling for days, but each delegate example is different than the next. I'm not even sure that the delegate handling is my problem.

I apologize if this seems like a simple question, I am new to WPF and do not yet know what I don't know. None of the books I've purchased seem to go into any detail regarding my particular situation.

Thank You

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

ABitSmart16-Feb-09 16:36

ABitSmart

16-Feb-09 16:36

frosty_4th wrote:
"The calling thread cannot access this object because a different thread owns it"

You are trying to access the UI from a non-UI thread.

In WPF, you need to use the Dispatcher for cross-thread UI interactions.MSDN[^]

e.g.,

public void Test()
        {
            Button theButton = button1 as Button;

            if (theButton != null)
            {
                // Checking if this thread has access to the object.
                if (theButton.Dispatcher.CheckAccess())
                {
                    // This thread has access so it can update the UI thread.      
                    theButton.Content = "Hello";
                }
                else
                {
                    // This thread does not have access to the UI thread.
                    // Place the update method on the Dispatcher of the UI thread.
                    theButton.Dispatcher.BeginInvoke(DispatcherPriority.Normal,
                        (Action)(() => { theButton.Content = "Hello"; }));
                }
            }  
        }

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

Pete O'Hanlon16-Feb-09 22:25

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

16-Feb-09 22:25

Sacha Barber proposed a fantastic extension method that you might want to look into. It's called InvokeIfRequired, and looks a bit like this:

public static void InvokeIfRequired(this DispatcherControl control, Action operation)
{
  if (control.Dispatcher.CheckAccess())
  {
    operation();
  }
  else
  {
    control.Dispatcher.BeginInvoke(DispatcherPriority.Normal, operation);
  }
}

Then, it's simple to do:

Dispatcher.CurrentDispatcher.InvokeIfRequired(()=>{ theButton.Content="Hello"; });

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

My blog | My articles | MoXAML PowerToys

frosty_4th16-Feb-09 23:41

frosty_4th

16-Feb-09 23:41

Thanks Pete !

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

Pete O'Hanlon16-Feb-09 23:49

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

16-Feb-09 23:49

You're welcome.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

My blog | My articles | MoXAML PowerToys

gvijaianandmca30-Sep-09 1:10

gvijaianandmca

30-Sep-09 1:10

when u get the solution pls post it

Re: WPF, Delegates, The calling thread cannot access this object because a different thread owns it

Pete O'Hanlon30-Sep-09 2:11

30-Sep-09 2:11

It's already been posted in this thread. Which bit confused you?

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

Another Silverlight upgrade headache - Hashtable [modified]

devvvy16-Feb-09 14:34

devvvy

16-Feb-09 14:34

I've got a util class which contains a non-Generic Hashtable.

class Person
{

protected Hashtable _lstProperties;

public Hashtable Properties
{
get { return _lstProperties; }
set { _lstProperties = value; }
}
}

And property really is a template class ...

class Property<T>
{
...
}

And Silverlight stipulates that every collection be System.Collections.Generic - this means even if I hand out the source code, it can't be consumed from Silverlight.

Is Silverlight Team basically saying there'll be no need for collection of unknown types in future? That everything SHOULD be know in compile time? They actually call Hashtable OBSOLETE? Anyone has email to silverlight and WPF team?

Re: Another Silverlight upgrade headache - Hashtable

Mark Salsbery17-Feb-09 5:18

Re: Another Silverlight upgrade headache - Hashtable

17-Feb-09 5:18

Dictionary<TKey, TValue> would be the class you want I believe.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

devvvy17-Feb-09 15:25

devvvy

17-Feb-09 15:25

wrong answer - you're assuming
a. you know person's property type in compile time
b. all properties of same type

dev

Re: Another Silverlight upgrade headache - Hashtable

Mark Salsbery17-Feb-09 15:34

Re: Another Silverlight upgrade headache - Hashtable

17-Feb-09 15:34

devvvy wrote:
wrong answer - you're assuming

Wrong complaint department. I'm just passing MS's recommended replacement.
(or don't shoot me, I'm just the messenger Smile | :)

)

AFAIK only generic collection classes will be used in Silverlight, as you've read.
The choice was made for framework size and performance reasons, as were many many other
trade-offs.

If you want to plead your case, you could post on the Silverlight Forums[^].

I'd be interested in MS's response...

Cheers,
Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Mark Salsbery17-Feb-09 15:39

Re: Another Silverlight upgrade headache - Hashtable

17-Feb-09 15:39

Mark Salsbery wrote:
If you want to plead your case, you could post on the Silverlight Forums

You already did - never mind Smile | :)

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

devvvy17-Feb-09 22:53

devvvy

17-Feb-09 22:53

Some other guy gave me a suggestion

Dictionary<string,>

This will do!! I may not know what sort of object it will be in runtime but I know they all derived from "Object"

I am an idiot, forget my comment!

dev

Re: Another Silverlight upgrade headache - Hashtable

Mark Salsbery17-Feb-09 22:55