BUG: Rename cmd with embedded regexp corrupts context menu

This is a rather confusing bug so if it doesn't make sense on the first go-around please bear with me. See attached zip file with pdf's documenting the problem.

BUG (ref. DOpus.All FilesFolders.Corrupt):
adding rename commands with embedded regular expressions to the "All files and folders" file type context menu corrupts that file type as follows:

  1. added to "All files and folders" file type context menu:
    Move < sub-menu >
    Move to Subdir Rename REGEXP PATTERN (.+)(..)TO \1_file\0
    Move to Parent Rename REGEXP PATTERN .+ TO .\\0

  2. result

  • the "Opens With" state for the "All files and folders" type changes from empty to "Rename REGEXP PATTERN".
  • Attempting to execute the "Move to Parent" command from the context menu on a selected object in DO causes the windows "Open With" dialog to pop up asking for a program to run on that object.

WORKAROUND (ref. DOpus.All FilesFolders.Fixed.pdf):

  1. Created rename presets for the "Move to Subdir" and "Move to Parent" operations and called those from the context menu code rather than calling the rename commands directly.
    Move < sub-menu >
    Move to Subdir Rename PRESET ="M 2 -Move to Subdir "
    Move to Parent Rename PRESET ="M 1 -Move to Parent "

  2. result

  • Commands work as expected
  • Note that the "Opens With" state for the "All files and folders" type is empty which is what I would expect it to be.

Mark aka Maynard
dopus.9.1.1.6.maynard.122708.zip (951 KB)

OK. I understand what happened here. I neglected to double quote the regular expression strings. Doing that fixed the problem....

REGEXP PATTERN=".+" TO ".\\0"

However, I still think the corruption I experienced is a bug. The problem was not obvious, and trying to isolate the source required clearing and re-piecing AllFilesystemObjects.oxr back together again one piece at a time.

Mark

I tried adding the original commands to the All files & Folders submenu but it didn't seem to create any problems, except that the commands didn't work properly (as you said & solved in your reply).

What do you mean by that? The screenshot in both versions of the files shows blank. Or are they the same screenshot and the added text in the red box indicates what you saw in the past? Either way I don't it, though it could be because a bug with hidden sub-menus was fixed in 9.1.1.7 since this message was posted. Maybe that fixed it as well or maybe the problem only happens if the menu items are added in a certain place...

I can't think how some quotes missing from a command would change the open-with string, though. I'd expect the quotes to only matter when the command was actually run.

BTW, A zip containing separate text and image files would be much easier to work with than a zip with two PDF files, especially when it's two versions of data (difficult to diff/compare text, and especially images, in two PDF files) or data you might want to import (hoping the PDF line-wrapping etc. hasn't damaged it). I do appreciate the time it must've taken to compile the PDFs and the amount of detail in them; just saying it'd be easier to work with text/image files instead of having them compiled into PDFs.