INTERACT FORUM
Windows => Plug-in Development => Topic started by: scott_r on January 13, 2004, 03:07:16 am
-
The MJViewItemAutomation interface assumes that the "Populate Tree" option is checked when dealing with view schemes.
My understanding of the MJViewItemAutomation interface is that it provides us with a way to walk the existing tree. At present, I need to use the MJSchemeAutomation to walk the Media Library correctly and MJViewItemAutomation to walk Playlists.
This would be OK, but MJViewItemAutomation is much faster and provides quick ways to test if a node has children, which comes in handy when recursing over large Disk Location schemes.
Please change MJViewItemAutomation to accurately reflect the current tree, that is, respecting the "Populate Tree" option.
Thanks heaps,
Scott.
-
Scott,
This wouldn't be much good though if done like this because it means we dont have any way of letting the user refine searches as we cant replicate the panes (return a list of all values for a field) and have no way of working out what the pane values are.
This is pretty much the ONLY way we have of letting the user browse to files in the plugins.
Sure it'd be great to be able to just find out the basic view structure or to mimic the tree in MC exactly but ideally that would be a parameter (MJViewItemAutomation(populate as Boolean)).
Right now though just do what I've done and you were thinking about doing. Get the nodes to be created as the user expands the tree so it's not all at once.
I've already got this working (although not the smoothest implementation yet - supposedly it works better in .net)
-
I agree - I just think that the functionality that you describe would be better placed in MJSchemeAutomation as opposed to MJViewItemAutomation. My "View" of the MJViewItemAutomation interface is that it provides a way for us to walk the current tree. MJSchemeAutomation on the other hand should allow for getting View Scheme specific stuff.
And yeah, I've got the tree working fine in .net now, which is great. There are also other things I'm doing to the plugin so it will be included later.
Nice talking to you,
Scott.
-
It's a little tricky because we want children for the view item, even if the tree doesn't have them. This is what Hairstyle uses.
Maybe we can make it optional somehow.
-
It's a little tricky because we want children for the view item, even if the tree doesn't have them. This is what Hairstyle uses.
Maybe we can make it optional somehow.
That would definitely be great.
If you make it so a parameter needs to be passed, couldyou set it up so it has a default parameter as well though so it could still be called without one (this would allow for backwards compatibility). I'm not sure if thats possible in whichever language you code in. I know it is in PHP.
Also, having the values for a VS group mixed in with the other VS's inside that group is REALLY confusing.
Would it be at all possible or would u consider maybe instead of mixing it in, having it inside an artificially created VS called: <this View> or something so it remains as a unique VS not with it's data mixed in with the other VS's which gets really confusing.
-
It's a little tricky because we want children for the view item, even if the tree doesn't have them. This is what Hairstyle uses.
Maybe we can make it optional somehow.
A boolean value specifying wether or not to return "invisible" child nodes would be the best bet. Just overload the function so that no parameters keeps it how it is... but you know that ;)
Scott.
ps. Thanks for the reply, Matt :)
-
Scott,
Three choices would be better:
- Fill Tree
- Dont fill tree
- honour user settings (match their own tree)
-
Nila,
Brilliant idea :)
Scott.