Contenty Type Folder Format that Uses Custom Columns is not Working Well for "Search Results"

Help & Support
1

Please try to reproduce this misbehavior. It could be caused by a coding error on my custom column script, but I don't see any and there is no error message, so it could also be some sort of broken interaction between it and Opus. I tried on a fresh install on a VM and it happened there too.

Settings:

  1. Content Types system is enabled, so that Content Types Formats are applied automatically;
  2. There is a File Type group that includes the .eml extension;
  3. There is a Content Types Format for that group and it uses custom columns from the script Columns for Electronic Mail Format.7z (2.9 KB).

[You may use this .eml file to test: Mail.7z (286 Bytes). For the columns of the script, select Date, From, To and/or Subject.]

Trigger:

  1. Go to a folder that contains one or more .eml files. [May be a folder with the single file provided above.]
  2. Make a search for "ext:eml" using the Windows Search functionality.

Results:

The "Search Results" folder displays correctly the mail file(s) and the columns but does not display the values of the custom columns from that script and the the progress circle keeps spinning forever.

Expected results:

The values of the columns should be displayed.

Observations:

  1. If, after the search, the user override the folder format to another without the custom columns, e.g. "Reset to folder's format", and refresh the tab (F5), the search concludes correctly (the progress circle stops spinning).
  2. The values are displayed correctly when accessing the search as a stored query and everywhere else that does not involves a search (collections, common folders, infotips).
2

Is the script being called but then never returning a result (maybe getting stuck calling something else) for one of the files? That would cause what you are seeing.

You could check by making the script output something to the log when it is called for a file, and just before it returns a result.

3

The script does output the expected values if a print statement is declared right after the command that passes the computed values to the Map that holds the values. e.g.:

scriptColData.columns(config.columns[i].name).value = iValue; print(iValue);

After settings the values for the map, the script returns. So that is where it ends.

As far as I can tell, that indicates everything is right with the script.

4

Probably solved by this:

I will mark this as resolved after the next version is out (if it is indeed fixed).

5

Yes sounds like the same problem. Thanks!