load file list into scrap
Moderators: fgagnon, nikos, Site Mods
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
load file list into scrap
It would be useful to be able to load a list of files (from a text file) into a scrap.
I run many scripts that generate lists of files that I can send to other programs... sometimes it would be nice to see such a list of files in a scrap pane.
It would also be useful to be able to export the contents of a scrap to a text file list.
Currently scrap panes only save/load cida files, so a workaround would be to convert between cida and text files. Is the format of cida files documented anywhere? Googling basically tells me that cida files belong to xplorer2.
I run many scripts that generate lists of files that I can send to other programs... sometimes it would be nice to see such a list of files in a scrap pane.
It would also be useful to be able to export the contents of a scrap to a text file list.
Currently scrap panes only save/load cida files, so a workaround would be to convert between cida and text files. Is the format of cida files documented anywhere? Googling basically tells me that cida files belong to xplorer2.
Re: load file list into scrap
have a text file with one full path per line, then copy the text and paste in a scrap
Re: load file list into scrap
You know, I've spent time trying to script my way through this, but what seems like a simple thing is actually rather messy (but by no means impossible) - yet the problem is, it's just not worth doing because it adds an extra layer of abstraction to what should just be an instinctual thing. By other threads we've learned that CIDA's are structures of object PIDL's ("Pointers to item ID Lists") - which nikos has stated are just directly dumped to a file... yet deciphering this stuff is rather Byzantine (in other words, "HDROP my-arse"). ![Wink :wink:](./images/smilies/icon_wink.gif)
Every time I start, I always just come to the conclusion that there's absolutely no logical reason to use a so-called CIDA format at all - virtually every programme in the known universe that can handle list-files (*.LST) already uses a text format that anyone can translate into anything else - or even just read by using human eyes. By relying on PIDL's, the CIDA depends directly upon the objects actually existing to be loaded properly, which is no doubt convenient for Nikos, but hardly relevant to end-users who use things like x2 to insulate them from arcane filesystem minutia. What good is a list of files which cannot be modified (or, indeed, used in any way) outside of x2?
Essentially Nikos was just being completely lazy (and cruel) by dumping these structures to binary files wherein they interface with exactly zero other products in existence. Even Visual Studio uses the generic text .LST format.
Especially considering that x2 already can dump LST files directly (using the '$>' token), it's madness for me (or anyone) to expend a lot of effort doing something which is so back-ass-wards as to be plain ridiculous in this age of programmes exchanging information fluently.
Personally I would just deprecate CIDA completely, as it's really not worth much in the file-management world. Burn it. Burn it down good. And replace it with a comprehensive and purposeful LST format which anyone can use and manipulate in ways that Nikos (apparently) is incapable of even imagining - such as processing lists generated (and re-manipulated) within 3rd-party utilities, which could then be opened in x2 directly, without needless "copy/pasting" palaver.
(Yes, I'm grumpy today - but let that not detract from my point.)![Mad :x](./images/smilies/icon_mad.gif)
![Wink :wink:](./images/smilies/icon_wink.gif)
Every time I start, I always just come to the conclusion that there's absolutely no logical reason to use a so-called CIDA format at all - virtually every programme in the known universe that can handle list-files (*.LST) already uses a text format that anyone can translate into anything else - or even just read by using human eyes. By relying on PIDL's, the CIDA depends directly upon the objects actually existing to be loaded properly, which is no doubt convenient for Nikos, but hardly relevant to end-users who use things like x2 to insulate them from arcane filesystem minutia. What good is a list of files which cannot be modified (or, indeed, used in any way) outside of x2?
Essentially Nikos was just being completely lazy (and cruel) by dumping these structures to binary files wherein they interface with exactly zero other products in existence. Even Visual Studio uses the generic text .LST format.
Especially considering that x2 already can dump LST files directly (using the '$>' token), it's madness for me (or anyone) to expend a lot of effort doing something which is so back-ass-wards as to be plain ridiculous in this age of programmes exchanging information fluently.
Personally I would just deprecate CIDA completely, as it's really not worth much in the file-management world. Burn it. Burn it down good. And replace it with a comprehensive and purposeful LST format which anyone can use and manipulate in ways that Nikos (apparently) is incapable of even imagining - such as processing lists generated (and re-manipulated) within 3rd-party utilities, which could then be opened in x2 directly, without needless "copy/pasting" palaver.
(Yes, I'm grumpy today - but let that not detract from my point.)
![Mad :x](./images/smilies/icon_mad.gif)
Re: load file list into scrap
cida is the native tongue for shell item identification. Not all items have text paths (think virtual folders), especially for older windows, therefore the cida solution is the correct choice
Re: load file list into scrap
God forbid that such a thing in x2 should be actually user-serviceable. CIDA is superficially the right choice (if you think on the shell level), but it's worthless practically, because humans obviously don't think or work on the shell level - that is the whole point of x2's existence! What good is a format that is (by your own admission) wholly for internal-use only? I've had suppositories that made more of a contribution to the real world (albeit a smelly contribution) - butt hey [sic], anything is better than nothing. ![Wink :wink:](./images/smilies/icon_wink.gif)
x2 is quite capable of importing and exporting the LST format, so what's the big deal about actually implementing something that has a true tangible application towards real-world interoperability? Do you think that after 12-years the world is going to wake up and say "Hey, that CIDA thing really makes sense, everyone should use it!" Not a hope.
As it is (and as it has been from the beginning) CIDA is a worthless format (for real-world use) that should be completely hidden from the end-user, and instead the end-user offered something that they could actually use, understand, and reasonably manipulate outside of x2's aegis and feudal demesne.
When Commodore Perry sailed into Uraga Harbour to bully the shogunate, he only had a narrow and selfishly vague vision of the reality on the ground - in exactly the same way as playing the emperor with his head in the sand isn't befitting a desktop developer in this contemporary landscape. Especially when that landscape is being eroded daily by MS's careless attrition of its own products in a laughable pursuit of catch-up philosophy in an attempt at appearing forward thinking under the guise of a pretentious industry leadership.
x2 can do better than be a victim of this. And x2 can also do better than proffering "virtual folder" excuses, when recent events have shown that x2 ain't so hot in the virtual folder department in the first place.
![Wink :wink:](./images/smilies/icon_wink.gif)
x2 is quite capable of importing and exporting the LST format, so what's the big deal about actually implementing something that has a true tangible application towards real-world interoperability? Do you think that after 12-years the world is going to wake up and say "Hey, that CIDA thing really makes sense, everyone should use it!" Not a hope.
As it is (and as it has been from the beginning) CIDA is a worthless format (for real-world use) that should be completely hidden from the end-user, and instead the end-user offered something that they could actually use, understand, and reasonably manipulate outside of x2's aegis and feudal demesne.
When Commodore Perry sailed into Uraga Harbour to bully the shogunate, he only had a narrow and selfishly vague vision of the reality on the ground - in exactly the same way as playing the emperor with his head in the sand isn't befitting a desktop developer in this contemporary landscape. Especially when that landscape is being eroded daily by MS's careless attrition of its own products in a laughable pursuit of catch-up philosophy in an attempt at appearing forward thinking under the guise of a pretentious industry leadership.
x2 can do better than be a victim of this. And x2 can also do better than proffering "virtual folder" excuses, when recent events have shown that x2 ain't so hot in the virtual folder department in the first place.
Re: load file list into scrap
there is no such thing as LST format, it is all sorts for all sorts of programs
Re: load file list into scrap
There's no common thing as an unencrypted LIC format either, but that didn't stop you.
Obviously, I was speaking broadly - LST is a commonly understood (CSV-type) format of a simple text file which contains a CRLF-dessicated list of "things", most commonly this is a list of filenames, but can also be command-line params, etc.
For all intents and purposes they are always interchangeable with .txt files, I merely pointed it out by name because a normal install of Visual Studio happily associates itself with the .LST extension, and you never know when I might be spoofing you just for fun
. (Personally, I re-associate them with Notepad++, but that's me - it's still a "known" format.) The .LST extension is useful as it differentiates it from a normal text file, which then allows an application to know that the contents may be parsed differently (such as dropping a LST into a scrap pane would parse it out internally, not use the literal object) - that's how I handle them in the nonsense I write.
Use whatever extension you like ("MyFilesInteroperability.NikosHasABigBum"), just so long as the contents are human-orientated.![Very Happy :D](./images/smilies/icon_biggrin.gif)
Obviously, I was speaking broadly - LST is a commonly understood (CSV-type) format of a simple text file which contains a CRLF-dessicated list of "things", most commonly this is a list of filenames, but can also be command-line params, etc.
For all intents and purposes they are always interchangeable with .txt files, I merely pointed it out by name because a normal install of Visual Studio happily associates itself with the .LST extension, and you never know when I might be spoofing you just for fun
![Wink :wink:](./images/smilies/icon_wink.gif)
Use whatever extension you like ("MyFilesInteroperability.NikosHasABigBum"), just so long as the contents are human-orientated.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
- FrizzleFry
- Platinum Member
- Posts: 1241
- Joined: 2005 Oct 16, 19:09
Re: load file list into scrap
I did not know you could do that... I can script that...nikos wrote:have a text file with one full path per line, then copy the text and paste in a scrap
but I do agree with Kilmatead that there should be a text import/export file format for scraps...
Edit: in case anyone else plays with this at some point...
the lines you paste into the scrap must end in <CR><LF> (DOS/Windows mode)
Re: load file list into scrap
+1. I had requested this feature long back. I tried generating my own CIDA file but had to give up after trying hard due to lack of documentation/ sample code.FrizzleFry wrote:I run many scripts that generate lists of files that I can send to other programs... sometimes it would be nice to see such a list of files in a scrap pane.
Nikos, since you are the most knowledgeable about CIDA, please do all of us a favor and create a simple command line tool which accepts a text file and emits CIDA.
Help! I'm an AI running around in someone's universe simulator.
Re: load file list into scrap
lynch mob!
ok, I'll add a text import command somewhere
ok, I'll add a text import command somewhere
Re: load file list into scrap
Thank you Nikos. Please add the option to load and save scrap content as text files in the scrap context menu. I would really like to leverage this feature in the miniscrap pane. In the context menu, you can update the "Load contents..." and the "Save as..." dialogs to handle both cida and text files.nikos wrote:ok, I'll add a text import command somewhere
Help! I'm an AI running around in someone's universe simulator.
Re: load file list into scrap
[b]This is just a reminder!![/b]
Nikos,
please, please, PLEASE add the possibility to export AND import simple .txt, .cvs or other format files from/into scrap.
This could take away a lot of frustration from a (non-sophisticated) user (like me).
For the 2nd time I run into the same trap - tried to save scrap links into a named cida, read that back
later, was told 'some items could not be located' and the scrap window remained empty. So what about the
locatable links? I did a hex dump - all links were gone from the .cida - which might be in accordance with the specs but not very user friendly..
(Maybe I did something stupid - the idea of user friendliness should kick in here...)
So, again: please give a chance to save links (and restore) into/from a file simple and permanent.
Nikos,
please, please, PLEASE add the possibility to export AND import simple .txt, .cvs or other format files from/into scrap.
This could take away a lot of frustration from a (non-sophisticated) user (like me).
For the 2nd time I run into the same trap - tried to save scrap links into a named cida, read that back
later, was told 'some items could not be located' and the scrap window remained empty. So what about the
locatable links? I did a hex dump - all links were gone from the .cida - which might be in accordance with the specs but not very user friendly..
(Maybe I did something stupid - the idea of user friendliness should kick in here...)
So, again: please give a chance to save links (and restore) into/from a file simple and permanent.
Re: load file list into scrap
Actually, this may not take away as much frustration as you might hope. The reason is that when CIDA contents are imported, they are not "links to" objects (bear with me, the language is important), they are actually PIDL's (as stated in a post above), Pointers to item ID Lists. What this means is that unlike regular links [.LNK, reparse, etc] (which still remain even if the target they point to is removed), these PIDLs simply vanish when the physical ID itself (within the filesystem) for an object cannot be located. There's no way around this - scrap containers cannot hold/display a name for something that no longer exists.james_k wrote:This could take away a lot of frustration from a (non-sophisticated) user
In an ideal world, most users would imagine something like non-existing items being represented by flaming red text once imported - but the nature of scrap containers precludes that from being possible, as they cannot hold things which (literally) don't exist, text-paths or not.
The only way to retain "links" to items which don't exist is to actually use links, as the links themselves will remain valid objects regardless of whether their targets do or not.
Thus, even if the original list is saved in a human-friendly text format, any non-existing elements will be discarded upon loading - and the only way for the user to know which items were discarded is to manually compare the <before> list with the <after> display. With a text format, this is at least possible (whereas with CIDA it is not), but it's still far from truly user-friendly.
So... an estimated 18.3% Frustration may be saved - which is better than nothing.
![shrug :shrug:](./images/smilies/shrug.gif)
Re: load file list into scrap
Baring in mind that it only works for the locatable objects you could use try a workaround I used a couple of times. I copy the paths of the files in the scraps to the clipboard with alt-c and paste them in a textfile.
For reimport you can copy them from the text file again and use the import from clipboard of the scrap pane.
For reimport you can copy them from the text file again and use the import from clipboard of the scrap pane.
-
- Gold Member
- Posts: 428
- Joined: 2011 Jan 23, 18:58
- Location: Sydney AU
Re: load file list into scrap
@BRX - you're not alone, been doing that for some time. I was too scared to say so in this threat, in case I got hauled over coals by the Geek Nobility Ψ²BRX wrote:Baring in mind that it only works for the locatable objects you could use try a workaround I used a couple of times. I copy the paths of the files in the scraps to the clipboard with alt-c and paste them in a textfile.
For reimport you can copy them from the text file again and use the import from clipboard of the scrap pane.
I usually only want the scrap-list for a short while, so given I have a clipboard configured for 200 persistent items in a lifo-list, I rarely save the scrap-list explicitly.
I've always thought that CIDA was something you drank and PIDL was something you afterwards did
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
RP
Windows 10 Pro (64 bit) version 1809 - Xplorer2 version: Pro 2.5.0.4 [Unicode] x64 2014-06-21