XYplorer Beta Club

SFXAudio wrote:

admin wrote:The Select Property list should show everything available on your system. If Explorer can show that column then it should be listed in that list. No need for scripting.

Unfortunately MSFT, in all their wisdom, removed a bunch of the audio column functionality when going from Win XP to Win 7.

I think that's the reason why I'm not seeing the below parameters listed in the Select Property List.

-Audio Sample Rate
-Audio bit depth (the current "Bit Depth" option doesn't seem to be audio bit depth)
-Audio channels

These params are, however, displayed on the preview pane when clicking a single file, so there's gotta be a way to get them to display in columns...

Is there a custom column script I can use to display them? I'm working with uncompressed PCM .wav's right now.

Hmm, really? Shocking!

XY can extract the info by opening the WAV files (well, that's what the Shell does as well, IF it does it). So, yes I could add means to show that info in the columns.

But, I cannot really believe it. Can anybody here confirm this?

Well, I think I can confirm that these properties have been removed from Vista and later:
http://answers.microsoft.com/en-us/wind ... 7350b540c3

Interesting quote here:

I'm an audio professional in the games industry and I've just moved over to Windows 7 from XP. Being able to see Sample Rate quickly and easily without having to load up a wave editor really is a fundemental requirement when working with hundreds of audio files at a time. What a monumental c**k up by microsoft once again.

I know the majority of video editors use Windows (hence all the video info options) and most audio engineers us Apple, but removing the option to view basic information about audio files compounds the issue and makes sure it'll always stay this way.

Even with all it's problems, I'm missing XP Pro already. At least I can see the damn SampleRate!

Sorry in advance...


It just feels that between Extra Tags, Extra Columns, and Custom Columns there is a ton of room for improvement by tightening their integration.

Looking back with perfect vision...

The configuration for Extra Tags should have never been connected to the columns. It should be a separate dialog, maybe more like Manage UDC or part of Configuration > Tags, because Extra Tags are useful even if they are not displayed in the list, and their configuration has nothing to do with the columns.

Then Extra Columns and Custom Columns would actually be the same thing - Custom Columns, similar to what you just added but with the types Template, Extra Tag, and Script. This would bring Extra Tags into the list without tying their definitions to the columns. Template, as it does today, would allow the user to bring shell properties into the list but it wouldn't exactly encourage them to be used, as you are now.

Really with some smarts the three types could be eliminated here since extra tags could be accessible via variables and templates are just resolved strings. There is no practical difference between "<prop CameraModel>" and "return <prop CameraModel>;".

Shell Columns are a separate feature and could have been introduced before or after the above.



Right now I feel like we're missing out on a lot of synergy!

Pretty darn cool!
Thanks all, for the sample scripts.

Interesting bug in Win 7, with XY...0103:
I add a custom column by right-clicking the Name column in Details View, and putting a checkmark next to one of the custom columns in the droplist. This *does* add the column as expected--but it also has the affect of opening the 'Properties' dialog of every single file in the folder that is shown!

kunkel321 wrote:Interesting bug in Win 7, with XY...0103:
I add a custom column by right-clicking the Name column in Details View, and putting a checkmark next to one of the custom columns in the droplist. This *does* add the column as expected--but it also has the affect of opening the 'Properties' dialog of every single file in the folder that is shown!

Exactly the same happened here. I quickly opened a fresh one, but I couldn't repro, so I didn't report it. Win7x64

kunkel321 wrote:Pretty darn cool!
Thanks all, for the sample scripts.

Interesting bug in Win 7, with XY...0103:
I add a custom column by right-clicking the Name column in Details View, and putting a checkmark next to one of the custom columns in the droplist. This *does* add the column as expected--but it also has the affect of opening the 'Properties' dialog of every single file in the folder that is shown!

Yep, fixed it an hour ago. Upload soon...

SFXAudio wrote:

admin wrote:The Select Property list should show everything available on your system. If Explorer can show that column then it should be listed in that list. No need for scripting.

Unfortunately MSFT, in all their wisdom, removed a bunch of the audio column functionality when going from Win XP to Win 7.

I think that's the reason why I'm not seeing the below parameters listed in the Select Property List.

-Audio Sample Rate
-Audio bit depth (the current "Bit Depth" option doesn't seem to be audio bit depth)
-Audio channels

These params are, however, displayed on the preview pane when clicking a single file, so there's gotta be a way to get them to display in columns...

Is there a custom column script I can use to display them? I'm working with uncompressed PCM .wav's right now.

OK, got it! Here is a shot to prove it:

TheQwerty wrote:Sorry in advance...


It just feels that between Extra Tags, Extra Columns, and Custom Columns there is a ton of room for improvement by tightening their integration.

Looking back with perfect vision...

The configuration for Extra Tags should have never been connected to the columns. It should be a separate dialog, maybe more like Manage UDC or part of Configuration > Tags, because Extra Tags are useful even if they are not displayed in the list, and their configuration has nothing to do with the columns.

Then Extra Columns and Custom Columns would actually be the same thing - Custom Columns, similar to what you just added but with the types Template, Extra Tag, and Script. This would bring Extra Tags into the list without tying their definitions to the columns. Template, as it does today, would allow the user to bring shell properties into the list but it wouldn't exactly encourage them to be used, as you are now.

Really with some smarts the three types could be eliminated here since extra tags could be accessible via variables and templates are just resolved strings. There is no practical difference between "<prop CameraModel>" and "return <prop CameraModel>;".

Shell Columns are a separate feature and could have been introduced before or after the above.



Right now I feel like we're missing out on a lot of synergy!

Let me just finish my thing. I'm not able intellectually to change my mind at the moment... When I'm done we can throw it all over...

Here is how you config a column to show bit depth:

Multiple thots:

Is it difficult to extract the number of icons in a DLL or ICL file? What would the script for such a thing look like? Or maybe there's already a property for it(?)
---

It seems like it might be a good use of space to "combine" columns under certain circumstances... For example one column that provides the following:
IF file pattern = *.png;*.bmp;*.ico;*.jpg;*.gif;*.tif;*.tga
THEN property = Dimensions.
ELSE IF file pattern = *.dll;*.icl
THEN property = Number-of-icons
(obviously not real XY script ;-) )
---

So many properties to choose from! It would be clever if they could be categorized.. Like if they showed up in the list as
Video/Frame Rate
Video/Frame Width
Camera/Bit Depth
Camera/Orientation
Camera/Saturation
Music/Genre
Music/Bit Depth
Music/Track Number
Music/Length.

I guess some properties would have multiple categories (e.g. modification date).... This would make it easier to use XY's quick filter-as-you-type tool. Not sure if there are Windows limitations that would prevent this feature though.
----

Re file types patterns: why a different format?
.png;.bmp;.ico;.jpg;.gif;.tif;.tga versus *.png;*.bmp;*.ico;*.jpg;*.gif;*.tif;*.tga
Just curious.
----

Also curious: Would there be a performance difference if you use a built-in property (e.g. modification date) versus extracting the same info with a script??
----

Last comment: This is awesome Don--thanks so much for adding the Custom Column feature set! Good stuff.

Is it difficult to extract the number of icons in a DLL or ICL file? What would the script for such a thing look like? Or maybe there's already a property for it(?)
-> you again! No property for it, and no script possible AFAIK. Only I could do it, but just for you???


It seems like it might be a good use of space to "combine" columns under certain circumstances
-> planned!

So many properties to choose from! It would be clever if they could be categorized
-> not possible, it's owned by the shell.


Re file types patterns: why a different format?
.png;.bmp;.ico;.jpg;.gif;.tif;.tga versus *.png;*.bmp;*.ico;*.jpg;*.gif;*.tif;*.tga
-> both work, so no problem.

Also curious: Would there be a performance difference if you use a built-in property (e.g. modification date) versus extracting the same info with a script??
-> try it, but script is probably a bit slower.

Last comment: This is awesome Don--thanks so much for adding the Custom Column feature set! Good stuff.
-> yes

admin wrote:Is it difficult to extract the number of icons in a DLL or ICL file? What would the script for such a thing look like? Or maybe there's already a property for it(?)
-> you again! No property for it, and no script possible AFAIK. Only I could do it, but just for you???

We could find a way to do it via scripting.

I doubt we could do so quick enough for decent use in a column script, but one that tags a file with the information could work.

CC could show pilcrows for CRLFs when previewing text.
It's rather confusing seeing plain text in such a... plain view.

SkyFrontier wrote:CC could show pilcrows for CRLFs when previewing text.
It's rather confusing seeing plain text in such a... plain view.

Currently I show " " (2 spaces) in place of CRLF in the file list. IMO it looks better than pilcrow.

TheQwerty wrote:Sorry in advance...


It just feels that between Extra Tags, Extra Columns, and Custom Columns there is a ton of room for improvement by tightening their integration.

Looking back with perfect vision...

The configuration for Extra Tags should have never been connected to the columns. It should be a separate dialog, maybe more like Manage UDC or part of Configuration > Tags, because Extra Tags are useful even if they are not displayed in the list, and their configuration has nothing to do with the columns.

Then Extra Columns and Custom Columns would actually be the same thing - Custom Columns, similar to what you just added but with the types Template, Extra Tag, and Script. This would bring Extra Tags into the list without tying their definitions to the columns. Template, as it does today, would allow the user to bring shell properties into the list but it wouldn't exactly encourage them to be used, as you are now.

Really with some smarts the three types could be eliminated here since extra tags could be accessible via variables and templates are just resolved strings. There is no practical difference between "<prop CameraModel>" and "return <prop CameraModel>;".

Shell Columns are a separate feature and could have been introduced before or after the above.



Right now I feel like we're missing out on a lot of synergy!

OK, I did a bit of meditation and still fail to see why Extra Tags and Custom Columns should be joined. They are just too different. But it's not that important.

However: It is now time to implement my original plan of Context-Sensitive Columns. And indeed, I will have to write an additional interface for this ( ) where "Column Definitons" are assigned to Custom Columns. I will allow probably 32 "Column Definitons" for starters, and you can assign as many of them as you want to each of the 5 Custom Columns, and in any order. The Item Filter field in each Column Definiton plays a key role then in the question which Column Definiton is used for the current cell.

I'm still not totally sure how I can design this in a way that is not too clumsy to handle for the user. Needs more meditation... I like how you now can quickly re-define a column by right-click and I don't want to lose this ability. I currently don't see a way how to combine this with Context-Sensitive Columns...