FWIW, it's not the tree view population that takes a long time in App Get, but rather the XML parsing for each app. We have plans to make this better in a future version.
Thanks, Aaron -- Aaron Smith Web Development * App Development * Product Support Specialist Ai Squared * 725 Airport North Office Park, Fort Wayne, IN 46825 260-489-3671 * www.aisquared.com To insure that you receive proper support, please include all past correspondence (where applicable), and any relevant information pertinent to your situation when submitting a problem report to the Ai Squared Technical Support Team. > -----Original Message----- > From: Scripting [mailto:scripting- > bounces+asmith=aisquared....@lists.window-eyes.com] On Behalf Of > Jonathan Cohn via Scripting > Sent: Sunday, April 10, 2016 9:51 AM > To: David <trailerda...@hotmail.com>; Window-Eyes Scripting List > <scripting@lists.window-eyes.com> > Subject: Re: Treeview, takes an eternity to populate > > Hello, > I have noticed that the AppGet takes a while to populate the tree also. > Perhaps there is just too much memory management going on. > > Is it possible to only populate open branches with data? It would then cause > a brief slowdown when the branch is expanded, but not the extreme deals > you appear to be encountering. If the tree controller has to do a garbage > collection every 20 records or so, that could certainly slow down > performance. > > > Best wishes, > > Jonathan Cohn > > > > > On 9 Apr 2016, at 15:28, David via Scripting <scripting@lists.window- > eyes.com> wrote: > > > > Got a project running here, where I could use a bit of educated feedback. > > > > Imagine you have a selection of say 1000 CDs. You decide to catalogue all > your collection. You want to divide it into categories, and subcategories. > Even, under each subcategory, you may decide it would be nice to sorte each > title under its artist. And, somewhere in that herachi, you want to sort by > country of origin, and genre of the album. Poof, there we have one > description that might parallel with my project. > > > > To best handle the categorizing issue, I thought to have things lined up in > > a > treeview. And I have the XML dialog and all the coding up going at the > moment. Things categorizes pretty nicely, and it is quite easy to navigate the > tree, decide on the title you want, and have the further operation > performed from there, once I decide on what to do with the selected title. > > > > To give a bit of background, my "baby"-state of the project was done > without categories, and just lined up all titles in a listbox. > > > > Now, that everything is working, another issue arises, and that is where I > was looking for some feedback. > > > > When I had things just showing up in a simple listbox, populating this > > listbox > was done in a second or two - even with nearly 1000 entries. As I moved into > the tree-structure of my project, I am met with another reality. I can start > the > dialog, and it will take anything between 2 and 4 minutes for the computer to > populate the tree. At the most, I'd say there is 5 levels on the tree. In the > root of the tree, you will find approximately 40-50 entries (main categories). > > > > I thought maybe something was wrong with my code. so I dropped out the > lines of code that inserts the very "leaves" - if you want to name them so - > that is, the titles of the albums. In reality, now we only have a treeview, > with > main categories, subcategories, and artist names. No album titles. In this > state, the tree populates in a few seconds. Once I re-insert the lines that > populate the last level, that is the album titles, and that is where the big > number of entries comes in, things are back to the real slow processing time. > > > > For inserting the Album title, I am using the same method as when creating > the different branch levels. That is, first to create a TV.NewItem, fill in > its Text > and Data properties. Next, create an object pointing to the Parent Branch, in > my example the Artist name. And, finally, using the Children method to > Insert the entry of mine. > > > > Dim ArtistName: ArtistName = "Jim Reeves" > > Dim TVEntry: Set TVEntry = TV.NewItem > > TVEntry.Text = "Best Of" > > TVEntry.Data = 198901 > > Dim TVBranch: Set TVBranch = TV( ArtistName) > > TVBranch.Children.Insert TVEntry, TVILast > > > > This is a simplified snip-it of the code. I have not taken any security > > steps in > this snip-it. > > > > What puzzles me, is why it takes so long to populate all the different > branches, with all the titles. As I stated, creating a tree with no "leaves", > only > all the Category an subcategory-branches, took little or no time to populate. > And even filling a Listbox - although a far simpler constructed control - did > not > take an eternity either. > > > > Questions for your consideration, would be: > > - Is a Treeview supposed to be that slow to fill? > > > > - Am I overlooking something here, maybe, that could cause this slow > processing? I.e, could I have used another method of inserting the last level? > > - One alternative is, of course, to have all the categories and > subcategories show up in a treeview, and when the user have decided on > the one he wants to explore, he would tab over to a listbox that contains all > the entries in this subcategory. Haven't tried that last approach, and really > would have loved not to do it either, if possible. But I cannot afford to > leave > the user with a several minutes long processing time, just for his collection > to > be opened on the screen. > > > > Worst thing is, that I loose speech while the tree is populated. So > > seemingly > I cannot even ask the user to do other computing while he is awaiting the > long processing. I just wondered if the very nature of the tree-structure > conrol, is such that it only is an effecient way of displaying a few entries? > > > > Sorry for a rather lengthy explanation, but hope it all made a bit of sense. > As you may understand from the nature of the project, the individual entries > on the tree, are quite dynamic, so will have to insert them on the fly, and > cannot hard-code much other than the filling process, and then leave it to > the user to make the actual entries. Thanks for any feedback in this regard. > > > > > > -- > > David > > > > _______________________________________________ > > Any views or opinions presented in this email are solely those of the author > and do not necessarily represent those of Ai Squared. > > > > For membership options, visit http://lists.window- > eyes.com/options.cgi/scripting-window-eyes.com/jon.c.cohn%40gmail.com. > > For subscription options, visit http://lists.window- > eyes.com/listinfo.cgi/scripting-window-eyes.com > > List archives can be found at http://lists.window- > eyes.com/private.cgi/scripting-window-eyes.com > > _______________________________________________ > Any views or opinions presented in this email are solely those of the author > and do not necessarily represent those of Ai Squared. > > For membership options, visit http://lists.window- > eyes.com/options.cgi/scripting-window- > eyes.com/asmith%40aisquared.com. > For subscription options, visit http://lists.window- > eyes.com/listinfo.cgi/scripting-window-eyes.com > List archives can be found at http://lists.window- > eyes.com/private.cgi/scripting-window-eyes.com _______________________________________________ Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Ai Squared. For membership options, visit http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com. For subscription options, visit http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com List archives can be found at http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
