UDC: New

[jacky]

So, I see that new UDC that looks pretty cool. It's like a mixed of New Items & Copy From, I would say.

I was just looking at it, and so a got my usual questions

- <curitem> hmm ok. I got it now, I see how it works. So it basically extends the Ctrl+S feature as we can define a template for the name...

To be honest, my (silly) first idea was to use <curitem> on Name, not Clone ! Yeah, as a way to use the currently focused item's name in the new items we're creating. - Does that sound just silly, or ?

- I think support for portable features (relative syntaxes, ?:\ and ..\) would be nice.

- Question for later (scripting) : will it be possible to create, in one click/KS, a group of files at once, ideally using a batch rename template/pattern.

Right now when I need to do so I have to create one and copy/paste to get as many of them as I want (or copy them from elsewhere when possible), and then use F2 to batch rename.
In my dreams, in one KS I would be asked how many files, then the batch rename pattern (with a default of my choice) and bang: all done.
Now I could live easily with the KS creating a predetermined number of files instead of asking, too.

[Linkaday]

UDC | New

- i'm yet far from fully imagining how useful this will be for me, but i feel it in my veins. And i know for sure, there are not that many things as thrilling as witnessing XYplorer's evolution.

Jacky is so fast perceiving - he almost outdistanced my thought. But i'm proceeding on Jacky's first point:

If we could have <curbase> and/or <curitem> in name field - with <cur~>.txt wouldn't we get file annotation portable, no delicate context menu and properties handlers, just a hotkey plus dbl ENTER away opens a text file named right after the file say that i just had downloaded.

And slaphappy I´d Copy To Clipboard | Extended file info (or whatever convenient) and paste along with download path and whatever else i think should accompany my file for archiving purposes.

[admin]

Oh, yeah! jacky and Linkaday --- it has been in the air, and I probably would have smelled it, too, but you two were faster than me this time in seeing the great potential of the UDC New! Check out the new BETA and digest it.

About groups of new files... later... I still have to recover from the bliss of the current possibilities...

[Linkaday]

I just got hold of 6.60.0053! Wow, thank you sir, much more than i could dream of!!!

[admin]

I just got hold of 6.60.0053! Wow, thank you sir, much more than i could dream of!!!

Thank you for buying XY licenses for your friends!

[jacky]

Ok, so I have a problem : apparently I do feel like total nonsense makes complete sense in my mind

Code: Select all

    * UDC | New: the following variables refer to the Clone source if 
      there is one given, and not to the currently focused item: 
        <curtitle> 
        <curbase> 
        <curext> 
        <curver> 
        <myyyymmdd> 
      The variable name "cur..." might be confusing here, but the 
      behavior is expected and the logic is clear. If you create a new 
      file that's a clone of a certain other file, it would be total 
      nonsense to name that new file based on the name, date, or version 
      of the currently selected file! 

I do not agree this. I do see how this could be used and why it's cool, I do. But I also believe that on other behaviors to have those variables to relate to the focused&selected item would be expected behavior.

For instance, let's say I download lots of soft and once I tested them and whatnot, I like to create a little text file for each of them with my thoughts on it, maybe the URL where I found it, etc

For this, using a UDC: New with "<curtitle>.txt" for example could be great. But now, imagine I want such a text file to follow a predefined structure, and in order to make my life easier, instead of havig an empty file created I make a template and define it as clone.

Well, that was perfect until this latest change, because now my file is called "template.txt.txt" each and every time, which is nonsense !


So I would say that it would be best to let those variables to relate to the currently focused&selected item, it's simpler & avoid any confusion, and because to have variables relating to the cloned item might be good in another use of that feature, create new variables :
<srctitle>
<srcbase>
<srcext>
<srcver>
<syyyymmdd>

(I used src cause it relates to the source item, but maybe cln for clone(d) might be better...)

Ok, I'm done. I hope you will agree

PS: I'm sure I already asked for this, but look of those variables : yes, base-only is useful on occasion. So, couldn't we have a "Copy Item(s) Base Name" (ie. without extension) added on the "To Clipboard" menu please ?

[admin]

Ok, I'm done. I hope you will agree

Yep, makes sense. Pity that the "Tips" message box will get larger and larger... I will have to find another solution. Maybe similar to TOTD...

"<src...>" is good, too, as variable name. Actually, I had already thought about labeling "Source" what now is labeled "Clone"! Any objections?

<syyyymmdd> ... no, I will have to find something else here... maybe:
<srcdate m yyyymmdd>
<curdate m yyyymmdd>
It's long but in the long run it will pay off because of its clearness...

[jacky]

Yep, makes sense. Pity that the "Tips" message box will get larger and larger... I will have to find another solution. Maybe similar to TOTD...

Maybe you could show the TOPD window, loaded with a page filled with tips regarding this UDC

I had already thought about labeling "Source" what now is labeled "Clone"! Any objections?

Nope.

<syyyymmdd> ... no, I will have to find something else here... maybe:
<srcdate m yyyymmdd>
<curdate m yyyymmdd>
It's long but in the long run it will pay off because of its clearness...

Well, the only thing is that elsewhere in XY is used <d...> and <m...> for date variables (current/now and modified)
So then the new syntax should probably be valid everywhere else as well, but the old/current syntax should stay, you don't want to mess with the current config of users...

[admin]

<syyyymmdd> ... no, I will have to find something else here... maybe:
<srcdate m yyyymmdd>
<curdate m yyyymmdd>
It's long but in the long run it will pay off because of its clearness...

Well, the only thing is that elsewhere in XY is used <d...> and <m...> for date variables (current/now and modified)
So then the new syntax should probably be valid everywhere else as well, but the old/current syntax should stay, you don't want to mess with the current config of users...

That's my intention!

[admin]

PS: I'm sure I already asked for this, but look of those variables : yes, base-only is useful on occasion. So, couldn't we have a "Copy Item(s) Base Name" (ie. without extension) added on the "To Clipboard" menu please ?

What about this: another UDC category "Copy" (or "To Clipboard")!

Then you have all liberties you want: <base>, <path>, <ver> *

*PS: I'm thinking about dropping the "cur" -- it sucks in the long run...

Of course, a "free" UDC with verb "copy" could do to: copy <base>.

Finish. Dinner. Bye.

[Gandolf]

If you're going to do anything involving the clipboard (other than standard Windows actions) can you make sure it works with clipboard managers. I use ClipMate now, I used to use Yankee Clipper. DOpus totally screws up both the clipboard and Dopus if the clipboard manager is active.

Have a good dinner!!

[jacky]

What about this: another UDC category "Copy" (or "To Clipboard")!

Then you have all liberties you want: <base>, <path>, <ver> *

Sure, that could do it, yeah.

*PS: I'm thinking about dropping the "cur" -- it sucks in the long run...

Yeah, well, it was to differentiate "current" item and "source"/"clone" item, but it would make sense with <base> and <path> too, and extras such as <srcpath> still make sense as well. So consistency-wise it would work I think. It's only used here, or is there other places for such variables ?

Of course, a "free" UDC with verb "copy" could do to: copy <base>.

Well, for scripting yes, such a verb/action is required, definitely. But I was under the impression that there would be much more available that way that using "regular" UDC, etc like set_highlight, etc

As for my personal needs, just having the verb "copy" (probably "toclipoard" would be better, for consistency and to avoid confusion with "copyto") for scripting could be enough if I can have a way to create a menu, that I'll popup using a KS, and that menu can contain a few items that would all be related to the To Clipboard feature. (But not be the only menu for "scripted UDC")

By the way, I'm not sure how you intend to implement it exactly, but it would be really cool not to have a new UDC Category "Scripted" or something like that, but that we could create as many of such categories as we want.
Again, all in order to be able to organize things better, and also create appropriated menus to be poped up...

[jacky]

If you're going to do anything involving the clipboard (other than standard Windows actions) can you make sure it works with clipboard managers. I use ClipMate now, I used to use Yankee Clipper. DOpus totally screws up both the clipboard and Dopus if the clipboard manager is active.

I don't use one myself, but you can test that already : menu File|To Clipboard

[Gandolf]

Yes, I use "File | To Clipboard" regularly and it has no problems but, as I said, it's "other than standard Windows actions" that might result in strange behaviour.

[admin]

If you're going to do anything involving the clipboard (other than standard Windows actions) can you make sure it works with clipboard managers. I use ClipMate now, I used to use Yankee Clipper. DOpus totally screws up both the clipboard and Dopus if the clipboard manager is active.

Have a good dinner!!

Thanks!

No, I'm not going to anything with the clipboard that's technically different from what I'm doing now.

Generally: all UDC and scripting is only about workflow. There's nothing new in it technically whatsoever.