Unexpected behaviour with CreateFolder

Hi, I was wondering if anyone has any idea why the CreateFolder function seems to behave so oddly if it follows a Clipboard function...

For instance, another user submitted a Feature Request to add a function that would take any selected files and folders, create a new directory, and put them in the new directory. This seemed like something that Dopus should already be able to do, and it can... but the CreateFolder function not only creates the new directory in the current lister sourcepath, but also underneath any directories you've selected... the command syntax is like so:[b]Clipboard CUT CreateFolder {dlgstring|Specify folder-name to create and move files to...} READAUTO Clipboard PASTE Go UP [/b]So, the CreateFolder function is actually operating on the folders that were selected and processed by the Clipboard CUT command (same for Clipboard COPY) :frowning:. Nothing changes even if you add a Select NONE statement between the Clipboard and CreateFolder calls :confused: :cry:.

As a side note- another strange thing I noticed when trying to make this work was that when using the {dlgstring} with CreateFolder in this way, if a directory name with a space in it is fed to dlgstring, it actually creates 2 seperate folders... as if you've somehow invoked the [i]Create multiple folders (comma-separated) option except with spaces instead of commas as the separator...

It's possible CreateFolder is executing before Clipboard Cut. I know in ver 6 you have to proceed each line with "sync:" if you wanted to force each function to execute sequentially.

This is interesting.

Your side note is easy to explain. Because you want to create a folder that has spaces in the name, you must enclose the folder name in double quotes. e.g.

CreateFolder "{dlgstring|Specify folder-name to create and move files to...}"

But the part about the duplicate created subfolders reveals some interesting things. For one, when you clipboard cut a file or folder in DOpus, it is not actually cut at that time. It stays right where it was until you actually paste what was selected somewhere else, at that time it is moved. I wonder if this behavior is somehow tied to the undesired duplicated subfolders? What seems to happen is something like this:

is selected

And the above selected folder includes the

is the folder newly created by your button.

When you then Paste into that folder it results in this tree structure:


In light of this I think I would avoid the cut and paste idea and adopt the COPY MOVE method instead.


Hi drworm, thanks for the reply.
It's real funny... I had actually tried using the sync: dopusrt /cmd prefix at first but with JUST the CreateFolder call and it didn't work properly... the folder was not created redundantly under the selected dirs, but the selected items weren't being pasted/moved at all, and the Go Up was sending me all the way up to the desktop ;-(. But after reading your reply, I decided to mess around a little more with it and found that if I used the sync:dopusrt /cmd on every command, it WORKS! So here it is:[b]sync:dopusrt /cmd Clipboard CUT sync:dopusrt /cmd CreateFolder {dlgstring|Specify folder-name to create and MOVE files to...} READAUTO sync:dopusrt /cmd Clipboard PASTE Go UP [/b]Thanks dude, where there's a will there's a way!

Hi John, thanks for the reply... I was writing mine to worm before I saw yours.

The quotes around the {dlgstring} sequence work like you said (would have thought the sequence would take care of that but that's cool... no harm and good to know).

Without the extra usage of sync: on all commands the resulting duplicate tree structure is as you said above... right on. But it seems that between your's and worms suggestions everything works like you'd want it to now with:[b]sync:dopusrt /cmd Clipboard CUT sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE files to...}" READAUTO sync:dopusrt /cmd Clipboard PASTE Go UP [/b]... so that seems to be solved, thanks for your input.

But if it's just the same with you I'm interested in exploring some of the symantecs behind the things you mentioned regarding order of execution. For one, the Clipboard CUT seems (at least VISUALLY) to actually execute before the PASTE... I just say this because the selected items 'ghost' out before the CreateFolder dialog comes up. So I don't think it's necessarily related to the dupe folder creation... though that's odd because like I said... applying your logic results in exactly what I get for folder structure without the sync: prefixes... I was rather thinking that the CreateFolder call was operating not only on the current directory, but also on the selected folder as a target in which to create the specified new folder.

On a different subject, I thought about Copy MOVE... but couldn't see a way to make that work with a newly created folder because of order of execution... e.g. in order to move something, you've already got to have the new folder created for your destination... but if you call CreateFolder first, how do you reference that folder in a Copy MOVE to get your selected files into it. If you try a Copy MOVE HERE after using READAUTO during the CreateFolder, you lose your selected items for the Copy when you read into the new folder...?

Well, experienced some strangeness without doing the sync: on EVERYTHING, so:

To MOVE files and folders, and 'stay' in your current directory (I bound 'Alt + Insert' key to this):[b]sync:dopusrt /cmd Clipboard CUT sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE files to...}" READAUTO sync:dopusrt /cmd Clipboard PASTE sync:dopusrt /cmd Go UP [/b]To COPY files and folders, and change to the new directory (I bound 'Ctrl + Insert' key to this):[b]sync:dopusrt /cmd Clipboard COPY sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and COPY files to...}" READAUTO sync:dopusrt /cmd Clipboard PASTE [/b]Intermittently, the MOVE would seem to do everything the way I wanted, but wouldn't actually PASTE the files into the new folder... I'd have to go back into that folder and hit 'Ctrl + V' to paste manually? Seems fine now though... weird.

Hey John, or Worm, or anyone listening...

Someone raised a question in the original Feature Request topic that spawned this one asking about being able to re-use some of what we did here in order to:

a) Copy/Move the selected files to a New Folder of our making in the 'other' pane of a dual-pane lister...

or (what I'd rather do...)

b) Add a Drop Menu context item to not just Move Here, but to sort of do a Move to New Folder Here.

While I was typing this up going to ask some questions, I came across the following which seems to do the trick... enjoy Primus:

[b]sync:dopusrt /cmd Clipboard CUT sync:dopusrt /cmd Go {destpath$} sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE files to...}" READAUTO sync:dopusrt /cmd Clipboard PASTE sync:dopusrt /cmd Go {sourcepath$} [/b]It would be nice if there were a way to properly evaluate the {destpath} variable in the CreateFolder command itself so that you wouldn't have to "Go" to it first in order to actually create the new folder there, and thereby avoid seeing the screen switching back and forth with the Go commands. But when I try I get strange results... like it does get evaluated ok (unlike calling CreateFolder without the sync:dopusrt /cmd prefix, which actually creates the foldername itself with "{destpath$}" as part of the name), but then for some reason uses the READAUTO switch as part of the folder name rather than actually performing the READAUTO function, which subsequently then causes the Clipboard PASTE to just paste back to the original folder :frowning: . Oh well...

You could use something like this:

sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE files to...|{destpath$}}" READAUTOThe dlgstring dialog remains the same small size, unfortunately, but you get the full path in there and can add the folder you want to the end of it.

Hey now Noodel-guy! THAT'S the ticket... didn't realize you could use a pipe again at the end for that kind of effect. Cool THANKS! Added another function to the arsenal...

Note- like Nudel said, since the destination path appears in the CreateFolder dialog as a result of piping to it, the {dlgstring} dialog may look blown out, but if you expect to be moving files into deep directory structures often, you can mitigate it somewhat by just padding a bunch of spaces between the dialog text and the pipe to {destpath$}. Something I actually really like about having the destination path in there is that in case {destpath} is not what you'd expect (if using multiple listers and a keybinding) or if you drop your selections on the wrong folder (anyone but me do that often :slight_smile:?) at least you can see it in the dialog and correct it if you want by just backspacing over the wrong folder and replacing it with correct text... WAHOO!

So now, I'm just going to replace the old Copy/Move to New Folder stuff we did above with this new stuff:
Copy to New Folder Here...[b]sync:dopusrt /cmd Clipboard COPY sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and COPY items to...|{destpath$}}" READAUTO sync:dopusrt /cmd Clipboard PASTE sync:dopusrt /cmd Go {sourcepath$} [/b]Move to New Folder Here...[b]sync:dopusrt /cmd Clipboard CUT sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE items to...|{destpath$}}" READAUTO sync:dopusrt /cmd Clipboard PASTE sync:dopusrt /cmd Go {sourcepath$} [/b]
Thanks again Naked-L!

Name=Cut to Dest
Tooltip=Moves selected items to a new Dest folder
Func1=sync:dopusrt /cmd Clipboard CUT
Func2=sync:dopusrt /cmd Set State=Dest
Func3=sync:dopusrt /cmd CreateFolder "{dlgstring|Specify folder-name to create and MOVE files to...}" READAUTO
Func4=sync:dopusrt /cmd Clipboard PASTE
Func5=sync:dopusrt /cmd Set State=Dest

:opusicon: Porcupine

Hi Porc... this actually works the way X-Tender was looking for in his original post in the Features and requests forum (e.g. to move files into a new folder in the 'other' file window of a dual lister) but doesn't work as a drop menu context item... thanks tho, this is indeed another way to do it from current source/dest lister in a dual-mode lister...