Date variables in New Items

[ugus]

If XYplorer could read in a date syntax from the files in the New Items folder it would be really slick!

The date syntax could look like:

Test {yyyymmdd}.log

(If there are folders with sub folders that are copied maybe only the
root folder should have date format or...? have a switch in the syntax to include subfolders? )


/Ulrik

[admin]

Yep, spontaneous agreement! This is XY thinking!

Only the root items, I'd say. (Else would be much extra work)

[jacky]

Indeed, great idea!

[ugus]

Only the root items, I'd say. (Else would be much extra work)

Agree

PS: Later on you could even extend this ...with more variables
making this feature fully configurable

[ugus]

+ Menu Edit | New Items: Now, date variables are supported.
For example:
1. Create a file named "Log {yyyy-mm-dd}.txt" in the
NewItems folder in app path.
2. Go to some other folder.
3. Open menu Edit | New Items and select the new item (which has
been auto-added here magically)
4. A file called "Log 2007-09-17.txt" will be created!
(If today is 2007-09-17.)

Thanks a lot!

Maybe you can extend this, to include a kind of "action" syntax???

Some wild ideas!

Log {shell$normal}.txt - will create the file and open it directly after.
Test {run$nocopy}.bat - will just run the file (does not copy the file) with the folder path as an argument

[jacky]

Log {shell$normal}.txt - will create the file and open it directly after.
Test {run$nocopy}.bat - will just run the file (does not copy the file) with the folder path as an argument

Honestly, I think this is too much/complicated -- this is a NewItems feature, nothing else.

I'd rather have, as I mentioned somewhere, Catalog items to support date variables as well. That way, you could jump to/use in Move/Copy operations such files/folders !

TitlebarTemplate: in concordance with usage elsewhere in XY, I changed the brackets

I was gonna ask about this, but the other way around. Shouldn't you actually not use the brackets, I mean to be fair & consistent, the syntax elsewhere (Batch Rename, Move/Copy/Backup To, etc) does not use brackets !
Edit: Especially since brackets can totally be used in file/folder names!!

[ugus]

Log {shell$normal}.txt - will create the file and open it directly after.
Test {run$nocopy}.bat - will just run the file (does not copy the file) with the folder path as an argument

Honestly, I think this is too much/complicated -- this is a NewItems feature, nothing else.

OK, you'll maybe right that this is to complicated... this will be covered by the Hot Scripts feature I suppose.

I'd rather have, as I mentioned somewhere, Catalog items to support date variables as well. That way, you could jump to/use in Move/Copy operations such files/folders !

Neat idea.

[TheQwerty]

Log {shell$normal}.txt - will create the file and open it directly after.
Test {run$nocopy}.bat - will just run the file (does not copy the file) with the folder path as an argument

Honestly, I think this is too much/complicated -- this is a NewItems feature, nothing else.

I quite like this idea actually. For me nine out of ten times the step after creating the file is to edit it so it would be a small time saver.

The problem I see with it is the order of events. As it stands you get to rename/approve the name right after it is created.

Would including {shell$normal} cause it to use the default name or wait until you've approved the name?

Or is it ideal to make it more involved and have {shell$default} use the default name and {shell$approve} waits for you to approve the name before opening for edit?


I'm not sure I see the need for the {run$nocopy} version though. Currently you can put the bat file into the catalog and then drag and drop the path to achieve the same thing.

[ugus]

Log {shell$normal}.txt - will create the file and open it directly after.
Test {run$nocopy}.bat - will just run the file (does not copy the file) with the folder path as an argument

Honestly, I think this is too much/complicated -- this is a NewItems feature, nothing else.

I quite like this idea actually. For me nine out of ten times the step after creating the file is to edit it so it would be a small time saver.

The problem I see with it is the order of events. As it stands you get to rename/approve the name right after it is created.

Would including {shell$normal} cause it to use the default name or wait until you've approved the name?

Or is it ideal to make it more involved and have {shell$default} use the default name and {shell$approve} waits for you to approve the name before opening for edit?
.

I think {shell$normal} should use the default name, so that file is just opened for editing.

The normal argument was for normal focus (but this is maybe irrelevant, maybe "shelled New Items" just should open the file with normal focus)

... so maybe is it better to use

{shell$default} Shell the file in normal focus (no name editing)

{shell$approve} Think you need a msg prompt here (for handling
the events) , the user keeps the default or changes it and then the file is opened.

I'm not sure I see the need for the {run$nocopy} version though. Currently you can put the bat file into the catalog and then drag and drop the path to achieve the same thing
.

Yes, you are right. {run$nocopy} is overkill...

[admin]

TitlebarTemplate: in concordance with usage elsewhere in XY, I changed the brackets

I was gonna ask about this, but the other way around. Shouldn't you actually not use the brackets, I mean to be fair & consistent, the syntax elsewhere (Batch Rename, Move/Copy/Backup To, etc) does not use brackets !
Edit: Especially since brackets can totally be used in file/folder names!!

I don't get it. What is the part that you don't like?

[ugus]

{shell$default} Shell the file in normal focus (no name editing)

{shell$approve} Think you need a msg prompt here (for handling
the events) , the user keeps the default or changes it and then the file is opened.

Don, can this be of interest? I know you have this kind of feature in catalog but couldn't this spice up the New Items feature even more

Anyway, I think the date variables should be translated in the menu.

Test {yyyy-mm-dd}.txt should display as Test 2007-09-17.txt in the New Items menu.

[jacky]

I don't get it. What is the part that you don't like?

Nah, nevermind, forget it, read things wrong, lack of sleep, things got mixed up, you're doing a fantastic job man, I love you, I'll go take a nap now!

[admin]

{shell$default} Shell the file in normal focus (no name editing)

{shell$approve} Think you need a msg prompt here (for handling
the events) , the user keeps the default or changes it and then the file is opened.

Don, can this be of interest? I know you have this kind of feature in catalog but couldn't this spice up the New Items feature even more

Anyway, I think the date variables should be translated in the menu.

Test {yyyy-mm-dd}.txt should display as Test 2007-09-17.txt in the New Items menu.

No, overkill.

Maybe it should, but it's not possible now for internal reasons.

[ugus]

No, overkill.

Maybe it should, but it's not possible now for internal reasons.

Ok, I see anyway thank you for implementing the date feature!

I really love this fantastic application!! Keep up the good work!