|
|
Post by George on Jan 9, 2021 13:05:56 GMT -5
Not even sure how to access the Extended Properties, but how on earth would we cope with the vast number of properties? MP3's have probably 30-40, video files a bunch more, other file types - God only knows.
Adding ANY column to FM is a major effort, let alone adding multiple ones. Unless you have some magic idea here, I don't hold out much hope.
George
|
|
|
|
Post by George on Jan 9, 2021 16:08:50 GMT -5
I've looked at the FM Display routine. Frankly, there's no way I'd tackle adding 1 or 2 more columns to the available columns, let alone some more variable number. With the various combinations and the column sorting stuff, and the differing column hi-lighting depending on what column is the sort key, I just don't see how to manage it without some total revision to the way FM display is done.
Also, some web browsing and looking through the PB forums doesn't come up with any easy way to read the Properties. And let's call them Properties, not Attributes. Attributes are the RO, Hidden, etc. kept in the normal directory info. Properties seem to be kept in an alternative, much like the ADS streams.
Sorry.
|
|
|
|
Post by mueh on Jan 10, 2021 2:57:38 GMT -5
Hi Robert ! Are you aware of TBASS_SampleFromFile.tbasic in C:\thinBasic\SampleScripts\TBASS\ ? You should be able to invoke the tbasic script in FM .  |
|
|
|
Post by George on Jan 10, 2021 11:06:47 GMT -5
One of the biggest problems is the way FM stores all this data, it's a array of a structured TYPE.
TYPEs in PB are quite rigid.
No dynamic STRING fields, only fixed length strings.
No modification of the TYPE structure during execution.
So .. now lets add some variable number, of variable length strings to this equation. See the problem? And that's ignoring all the problems with sorting and displaying and hi-lighting all the info.
As to the COM interface, SPFLite right now does no calls to any COM interfaces, there's been no need, another new are to explore.
Yes revising FM would be "interesting", but it's a very large change.
George
|
|
|
|
Post by George on Jan 10, 2021 12:57:35 GMT -5
Robert: Found some code to retrieve Properties. To use it requires use of the alternate set of WinAPI Include files created by Jose Roca. His are much more complete and thorough than the standard API's provided by PB. This isn't a problem, it's just a swap. In there is an INC file with the GUID values of all the defined Windows Properties (679 of them). Certainly the majority of them are for weird, oddball filetypes. And looking at the sample property extract program, it isn't just a matter of retrieving Properties as TEXT, some are returned as DWORD. E.G. An MP3 Duration is returned in 100ns units, so needs conversion to something more usable. I'm sure other Properties will also need 'massaging' to become usable values for FM. So it isn't a matter of asking for an enumeration of available values, and then asking for them one by one. This could get quite involved as many will need these custom formatting routines.. Just as a FYI, I've attached the INC file with the known Property identifiers. George PropKey.inc (344.49 KB) |
|
|
|
Post by George on Jan 10, 2021 14:51:32 GMT -5
Not sure, the keys are grouped, some are called MUSIC, some AUDIO, IMAGE, PHOTO, MEDIA etc. There are just sooooo many. We can't think of this as just supporting our music libraries. There are many non-text items. There are some called multi-text? (I assume multiline text). This is non-trivial when we're talking a general FM.
George
|
|
|
|
Post by Stefan on Jan 12, 2021 15:54:36 GMT -5
Guys,
[This entry revised and tidied up - I wrote it rather hastily last night]
I use software called EXIFTOOL by Phil Harvey. You can find it here exiftool.org/Even the tool is of no other use, its documentation will help you understand the hierarchy of the TAG storage within the media files. It works with a huge number of TAGs, common in both audio and video circles.
Access may be less of an issue than subsequent display.
EXIFTool comes as a Windows command line tool but also as a PERL library, offering an number of methods to read and write tags which is probably callable from PowerBasic.
I reckon it would be horrid though to provide left/right scrolling in the FM display to show a variety of columns, even if they are truncated to a fixed length.
EXIFTOOL is my 'GOTO' utility around which I wrap some REXX to do things like
- renaming photographs from different sources (people, cameras, etc) according to date/time taken, so they appear in the correct sequence during a slide show,
- fixing timestamps when I forgot (again!) to reset date and time after the camera's battery ran out
- manipulate MP3 file metadata without resorting to expensive specialist programs - bulk-editing free-form TAGs like the iTunes COMMENTS field. etc
I assume you known that Windows File Explorer can natively display a host of 'extended attributes' as you called them (right-click a column heading and select from the list that appears (note the 'More' entry at the bottom). Left-clicking one of these columns will sort the file list as usual. Length is certainly one of those fields.
Of course, in a folder with a lot of files, the time taken to display the initial view will be a lot slower when it is sorted by a column that references values for which Windows needs to read every file.
|
|
|
|
Post by George on Jan 13, 2021 11:54:59 GMT -5
I have some code now which would read these Properties. The real problem is in several parts. - Expanding the array used by FM to store the current display contents. Possibly it could be expanded to allow for 'n' extra (3 ??) property fields of some max size (fixed - like 64 or whatever)
- Provide a means to assign which properties to the new slots, and the desired screen display width.
- Add the 3 slots (Prop1, Prop2, Prop3) to the list of available columns.
- Figure out how to have different properties for different folders (Music, Videos etc.)
- Figure out how to display all this stuff. Scrollable? Whatever, it will be a very difficult change to make.
A significant effort.
George
|
|
|
|
Post by Stefan on Jan 13, 2021 13:03:49 GMT -5
Robert I'm still not quite sure how FM displaying these 'tag' fields would be helpful. Forgive me if I'm being dim.
Windows File Explorer already has the facility to display a whole bunch of them (admittedly, by no means all) and it can sort the list accordingly (admittedly on only a single sort key). What is there to gain by adding FM support to do this 'as well'? The file format/type is not directly 'editable' so without new specialised SPFLite functions/commands to operate on such files, how is access via FM useful?
I guess a really cruel(!) person could imagine a 'FF-like' command to create a FOUND list of files matching a selection/combination of TAGs.
And file-level commands like Rename, Backup, Clone, Touch, etc could be more easily applied to such a selection.
I suppose, using XFORM, one could potentially read and modify the TAGs in such files (you're the expert in XFORM), but that's already doable today without fundamental changes to FM. I have nothing against the proposal and I think the ability to read and modify TAGs might be 'cool', but I wonder if SPFLite's File Manager is the right front-end. I think a bespoke 'front-end' utility, similar to MP3Tag, to 'manage' such files is a perhaps a better approach.
|
|
|
|
Post by George on Jan 13, 2021 15:02:59 GMT -5
Guys: I agree this is a significant piece of work. And my development philosophy has always been to do things in very small steps, even if that means the next step has to revise/update something the previous step did. I am not the "design the whole thing, and then recode it to the final result in one big step" type of guy. To me that has always proved to be too big a debugging jump in one go. So many things have changed there's no simple way to zero in on where an error is.
Maybe an initial step might be to figure out the FM horizontal scroll, that could be useful today. I figured it should always keep the Filename locked to the LH side and only scroll the remaining fields, but then, how much space to allocate for the filename? Questions, questions.
|
|
|
|
Post by George on Jan 13, 2021 17:01:55 GMT -5
Robert: I know little about MFC, but almost certainly it would require the whole SPFLite dialog to be converted to it. I doubt that 1 tab in a 'normal' dialog could access any of the MFC support. If so, that's a non-starter.
George
|
|
