Dreadlau wrote:windcrest77 wrote:brs_manamal1 wrote:This is right on target showing
COLLAPSED "TRACKS" with the
ability to expand when you WANT TO saving hours of scrolling and allowing users to easily manipulate the library especially when tagging. I used to leave all tracks collapsed and only leave tracks open on albums with tagging issues so when I happened across them again I would know that there was work to be done on the tags or some other issue within. this is not optional for me and before anyone says it(again) I don't want to use another stupid view, this is what I need for a very LARGE library requiring tons of work!!!!! I'm willing to do whatever is necessary to achieve this!!!!
I don't understand why media monkey which in my opinion is the best player/organizer out there right now would not implement this after years of people begging for it....are you guys serious really!!!! Give it up Monkey, we need this one!
I think this is what I was asking about a few weeks ago, something that combines a grid with a tree in the same main rectangle. But I was thinking that the tree hierarchy would morph itself automatically to whatever column you last sorted on or whatever column you told an autoplaylist to sort on etc. So if you clicked a different columnn for sorting in the grid then the tree / grid plus signs would automatically group the whole grid contents by that new sort sequence. Lets say my autoplaylist was sorted initially by
BPM; then by
rating; then by
artist; then by
title. In this case the grid would have BPM as the topmost group headers, expanding each unique BPM would give more group headers by artist, expanding an artist would give group headers by song name, expanding a song name would give all versions of that song (if more than one exists). IOW the tree/grid would always be aware of the current sort sequence and add expanding groups based on that until the sort hierarchy is exhausted. At the point one clicks to the innermost sort hierarchy you just get songs. My example is complicated in that it has sorting on BPM, rating, artist, title. If I were to re sort the grid heaer on just artist then the tree / grid would only group by artist, so expanding the artist would simply dump all the songs under it. If I were to re-sort by artist and album then you would see the tree / grid group itself by album within artist, etc. Is this clear?
viewtopic.php?f=4&t=59909
That's exactly what I want! Nice.
That would be absolutely perfect.
Yes the "tree/grid" control is fairly new but is becoming very popular in the business world application development. I often write specs for developers to use this type of control when I request database applications from IT at work. There is a control available that automatically handles all this grouping and sub-grouping for you, all you have to do is dump the raw data rows into the grid (initially with only the orderby and group by columns selected) and tell it how to order/group them in the grid. By default we usually just tie the sorting together with the grouping, so it goes like this (OrderBy a, ThenBy b, ThenBy c, ThenBy d) and (GroupBy a, ThenBy b, ThenBy c, ThenBy d), or you could truncate the grouping at "b" but still let the OrderBy go all the way to "d" if you dont want so much drill down to reveal the detail rows at a higher level but with duplicated data in columns c and d showing. At the point the tree is going to show full detail rows you do a last-second query of all the other columns that are not participating in ordering and grouping, this keeps the working set very small in the grid up to the point the detail-level is being asked to be seen so the non-group/order columns are needed from the database, up to that point that data can stay on the DB. Its really a very cool way to navigate databases. Currently with a flat (non-hierarchical) grid ALL the columns need to be populated all the time on all the rows, this makes the grid very heavy and when you sort it you see many rows with duplicated data in the column(s) you sorted on because no grouping occurred. People could still have that heaviness if they want, just add a checkbox indicating that the grid is not to be grouped at all even if I sort it, then it will behave like a flat grid again for people who want things the same as now. Or add a checkbox indicating that grouping should only go to a mx depth of 3 even if I sorted on 5 columns. There are a lot of posibilities; ordering and grouping are intrinsicly tied together but the grouping does not necessarily have to go as deep as the ordering is all Im saying, if you can put up with some repeated data in an ordered column. These grid controls can actually interpret an Order By and a Group By clause in the same SQL statement data source and adjust themselves on the fly in terms of both UI grouping and ordering. IOW I have seen developers do this with no lines of code other than running the query and binding it to the hierarchical grid control and setting the innermost level expand eventto run an "all selected columns" query. This will make a very light and fast grid data-wise.
