Skip to main content
User Experience

Return to Answer

added 2 characters in body
Source Link
Mayo
Mayo
  • 6.6k
  • 9
  • 31
  • 37

Here's my suggestion: you cannot know the size of the ENTIRE tree in advance. However, you do know how many objects are directly below the root, and once you scan one level deep, you also know how many objects are in the Nth object directly on the root. combining these 2 things, you might be able to use a dual progress bar setup, where you have 1 progress bar for the root level objects, and your second progress bar refers to the elements that are direct children to the currently progressing root level object. This method does have 2 disadvantages though:

  1. depending on the width and depth of the tree, it can give wildly wrong estimates;
  2. unbalanced trees (with nodes with significantly larger counts than other nodes) will have erratic progress bar behavior.

However, if you got any control over the object that the tree has (or can write extension methods), what you could do is write a recursive function that counts how many children the current item has, preferably something that's updated every time an item is added during the creation of the tree. The faster this method is, the better (using native properties is preferedpreferred over manual iteration), because it means you can use the answer suggested by Bobwise@Bobwise.

Here's my suggestion: you cannot know the size of the ENTIRE tree in advance. However, you do know how many objects are directly below the root, and once you scan one level deep, you also know how many objects are in the Nth object directly on the root. combining these 2 things, you might be able to use a dual progress bar setup, where you have 1 progress bar for the root level objects, and your second progress bar refers to the elements that are direct children to the currently progressing root level object. This method does have 2 disadvantages though:

  1. depending on the width and depth of the tree, it can give wildly wrong estimates;
  2. unbalanced trees (with nodes with significantly larger counts than other nodes) will have erratic progress bar behavior.

However, if you got any control over the object that the tree has (or can write extension methods), what you could do is write a recursive function that counts how many children the current item has, preferably something that's updated every time an item is added during the creation of the tree. The faster this method is, the better (using native properties is prefered over manual iteration), because it means you can use the answer suggested by Bobwise.

Here's my suggestion: you cannot know the size of the ENTIRE tree in advance. However, you do know how many objects are directly below the root, and once you scan one level deep, you also know how many objects are in the Nth object directly on the root. combining these 2 things, you might be able to use a dual progress bar setup, where you have 1 progress bar for the root level objects, and your second progress bar refers to the elements that are direct children to the currently progressing root level object. This method does have 2 disadvantages though:

  1. depending on the width and depth of the tree, it can give wildly wrong estimates;
  2. unbalanced trees (with nodes with significantly larger counts than other nodes) will have erratic progress bar behavior.

However, if you got any control over the object that the tree has (or can write extension methods), what you could do is write a recursive function that counts how many children the current item has, preferably something that's updated every time an item is added during the creation of the tree. The faster this method is, the better (using native properties is preferred over manual iteration), because it means you can use the answer suggested by @Bobwise.

Source Link
Nzall
Nzall
  • 2.3k
  • 12
  • 20

Here's my suggestion: you cannot know the size of the ENTIRE tree in advance. However, you do know how many objects are directly below the root, and once you scan one level deep, you also know how many objects are in the Nth object directly on the root. combining these 2 things, you might be able to use a dual progress bar setup, where you have 1 progress bar for the root level objects, and your second progress bar refers to the elements that are direct children to the currently progressing root level object. This method does have 2 disadvantages though:

  1. depending on the width and depth of the tree, it can give wildly wrong estimates;
  2. unbalanced trees (with nodes with significantly larger counts than other nodes) will have erratic progress bar behavior.

However, if you got any control over the object that the tree has (or can write extension methods), what you could do is write a recursive function that counts how many children the current item has, preferably something that's updated every time an item is added during the creation of the tree. The faster this method is, the better (using native properties is prefered over manual iteration), because it means you can use the answer suggested by Bobwise.