Finding replicant's original!

Ok, I’ve given up trying so here’s the question:

I made a Smart Group and got a buch of replicants of what I wanted. Then I did “something” (I don’t know what I did, please don’t ask) and since the Group was full of replicants (they were in red) I went ahead and erased the Group. When I “searched” for the same term in the whole DataBase (this time just “searched”, didn’t do a Smart Group) I got the same documents but all in red. Now I can’t find the originals.

Is there a way to find a replicant’s original? And how do I “convert” a replicant to an original.

By the way, (very off topic here) please do something with navagation; for example: if I do “Reveal”, it takes me to the place where the document in a search is, but if I want to go back to where I was, (using the small arrows) it takes me back to the last viewed document but not to its folder.

Thanks

Replicants make for a tricky concept. “Original” doesn’t mean anything, as there’s only one document that has multiple instances.

If a document has been replicated, the only way to end up with an “original” (Name in black font) document is to delete all but one of the replicants. It doesn’t make any difference which one of the set of replicants you decide to keep, while deleting the others.

Replicating a document, even a large one, adds only a tiny overhead increment (or size) to the database. So I have no hesitation about “filing” a document in more than one group by replicating it, or about creating smart groups or groups holding replicants of search results. Of course, I can delete a smart group or other group that contains only replicants without actually deleting information from my database.

If you have a document open in its own window and press Command-R (for “Reveal”) you will switch the display to a view, with the name of the document highlighted and showing its group location.

How to return to the original document or Search window? Select Window and then the document to return to it. Better than that, I use Exposé to display the open windows of DT Pro, and click on the desired document window. That’s fast. On my MacBook Pro, I’ve configured System Preferences to display the open windows of the frontmost application by “swooping” the cursor to the upper right screen corner. On my PowerMac with Mighty Mouse, it’s configured to display those open windows when I press down on the scroll button.

Wow! Thanks Bill for the promt response!!!

For some reason, when I do a search for one of the documents (Name) I have in red (replicants) I only get one found. So I was afraid to delete it because it only showed one and not 2 or 3 (the original with its replicants)

Search will display only one instance of a replicated item. (But Search will display duplicate items among the results.)

When you’ve selected the Name of a replicant, open the Info panel and note the number of replicants of the item.

Now go to the menu bar and select Go > Previous Instance (or Next Instance). Either will let you “walk” through your database and see the group location of each instance. If you want to delete one or more, make a note of the location of the ones to be deleted and then go to each and delete it.

Feature request: It would be nice, if the Info panel would show the locations of all replicants/duplicates - hidden by defauld, but it could be made visible by a “disclosure triangle”.

Louise.

I like Louise’s idea or something similar.

Just now I tried to located the original replicant by searching on metadata I keep in the Comments field. To digress… I borrowed from the shortcut techniques used by some system-wide systems (launchbar? quicksilver?) for quick access. For example, in the Comments field of my expenses file I have added the code “xe”. I keep a replicant of this file in another group I frequently have open. When I search on “xe”, the expenses file pops up; when I reveal that file via command-r, DT takes me to the original instance. Or so it seems from the replicants I’ve tested. Is this a good way to identify the original?

As far as i see - within one DEVONthink database - all replicants are exactly the same, there is no original. And that makes sense :wink:

As louise said, there is no original. :slight_smile:

If you add a comment to a replicant, all instances will have the comment.

After reading this discussion, I whipped up a script that will reveal the paths to the selected replicant. Devon think’s scripting is amazing, and allows a lot of features to be added…


---reveal replicants script 1.0 by Eric Oberle

tell application "DEVONthink Pro"
	set the_item to selection
	if the_item is {} then
		error "Please select a replicant."
	end if
	set the_item to first item of the_item
	set num_reps to (number of replicants of the_item)
	if num_reps is 0  then
		error "Please select a replicant."
	end if
	
	
	set the_name to name of the_item
	set the_selected_parent to {first item of the parent of the_item}
	set num_reps to (number of replicants of the_item)
	set the_parents to parents of the_item
	set clean_parents to {}
	set location_of_parents to {}
	repeat with i from 1 to count the_parents
		if {the_parents's item i} is not in the_selected_parent then
			set clean_parents's end to item i of the_parents
			set location_of_parents's end to (location of item i of the_parents) & name of item i of the_parents
			
		end if
	end repeat
	repeat until false
		set x to choose from list the location_of_parents with prompt "These folders contain replicants of " & the_name & ".  Double click (or hit ok) to open a given  parent in a new window, click cancel button to exit."
		if result is false then
			return
		else
			set the_index to my list_position(item 1 of result, location_of_parents)
			set the_location to item the_index of location_of_parents
			set the_record to (item the_index of clean_parents)
			set the_Window to open window for record the_record
			set full_location_of_the_replicant to the_location & "/" & the_name
			set the_replicant to get record at full_location_of_the_replicant
			set selection of the_Window to {the_replicant}
		end if
	end repeat
end tell


on list_position(this_item, this_list)
	repeat with i from 1 to the count of this_list
		if item i of this_list is this_item then return i
	end repeat
	return 0
end list_position




Please tell me if there are any troubles.

best,

Eric

The next release (1.1.2) will also introduce a “duplicates” script property, e.g. “duplicates of theRecord” will return all instances except theRecord.

Whow!
Maria, full of joy!

When Christian, when? :stuck_out_tongue:

Hopefully this month but maybe next month - we’re currently working on the kernel of DT 2 :slight_smile:

Ahaaaa. Sounds great. How many developers are working on this? (If I may ask.)

Not enough, especially as we’re currently also working on new projects :wink:

That’s what I’ve always informally called the “original” one, not knowing a more accurate name to describe it. It’s long frustrated me that searching for replicates was limited this way, which brings us to …

Thanks a bunch, Eric! This may turn out being very helpful for more easily tracking down replicated items on during a tedious upcoming project of merging two databases.

I still think that capability should be built-in, along with other “metadata-like” search functions I’ve previously requested (which I’m hoping will appear in DTP2 as a side effect of its architectural changes).

Yes, unfortunately. Running it from the script menu just causes DTP (v1.1.2beta2) to momentarily lose input focus then return to where it was. Furthest I get running it from Script Editor tosses up an AppleScript Error dialog – DEVONthink Pro got an error: List is empty – and highlights this code block:


choose from list the location_of_parents with prompt "These folders contain replicants of " & the_name & ".  Double click (or hit ok) to open a given  parent in a new window, click cancel button to exit."

Same result with different replicates selected. I’ll followup later if I can figure out what’s wrong.

I’m going to bet that one of your replicants is on the root of your database . Unfortunately as far as I can tell, devonthink’s scripting has no easy way to know whether one of the parents of a given record is on the root of the database. (I think it should, and that one should be able to get a “group id” of the “root of the current database,” and then test the "all parents of item x " against the “root of current database”. But Christian might might disagree, as there are philosophical issues involved as to whether the “root” of the database is itself a group or not. But that aside, as I could just simply not understand something here.)

At any rate, try this script…it should at least not give an error in the same crude way as 1.0 above did.



---reveal replicants script 1.1 by Eric Oberle 
set replicant_on_root to false
tell application "DEVONthink Pro"
	set the_item to selection
	if the_item is {} then
		error "Please select a replicant."
	end if
	set the_item to first item of the_item
	set num_reps to (number of replicants of the_item)
	if num_reps is 0 then
		error "Please select a replicant."
	end if
	
	
	set the_name to name of the_item
	set num_reps to (number of replicants of the_item)
	set the_parents to parents of the_item
	

	try
		if current group is "current application" then
			set current_group to {root of current database}
		else
			set current_group to current group
		end if
	on error
		set current_group to {root of current database}
	end try
	log current_group
	
	
	set location_of_selection to location of the_item
	if location_of_selection is "/" then
		log "selected item has replicant  on root"
		set replicant_on_root to true
	end if
	
	set unique_parents to {}
	set location_of_parents to {}
	
	----weed out replicants in same group as seleted one
	repeat with i from 1 to count the_parents
		log {the_parents's item i}
		log "location of parent=" & location of the_parents's item i
		if the_parents's item i is not current_group then
			log "**found unique replicant " & location of the_parents's item i
			set unique_parents's end to item i of the_parents
			set location_of_parents's end to (location of item i of the_parents) & name of item i of the_parents
			
		end if
	end repeat
	log "location" & location_of_parents as string
	if replicant_on_root then set location_of_parents's end to "root"
	
	if location_of_parents is {} then return
	repeat until false
		set x to choose from list the location_of_parents with prompt "These folders contain replicants of " & the_name & ".  Double click (or hit ok) to open a given  parent in a new window, click cancel button to exit."
		if result is false then
			return
		else
			set location_chosen to item 1 of result
			if location_chosen is not "root" then
				set the_index to my list_position(location_chosen, location_of_parents)
				set the_location to item the_index of location_of_parents
				set the_record to (item the_index of unique_parents)
				set the_Window to open window for record the_record
				set full_location_of_the_replicant to the_location & "/" & the_name
				set the_replicant to get record at full_location_of_the_replicant
				set selection of the_Window to {the_replicant}
			else
					set the_id to get id of the_item
				set x to get record with (the_id) in root of current database
				set x to {x}
				set the_Window to open window for record root of current database
				set selection of the_Window to x
				
			end if
		end if
	end repeat
end tell


on list_position(this_item, this_list)
	repeat with i from 1 to the count of this_list
		if item i of this_list is this_item then return i
	end repeat
	return 0
end list_position


Wise bet; there’s one replicant at the root.

Your detailed analysis and explanation was appreciated.

It works – thanks for the quick fix!

A couple minor anomalies:

• When the window for a replicated item’s group selected with the script opens in icon view the small “favicon” on the left end of the status(?) bar sometimes displays a seemingly random icon image, which remains the same if another item in that window with the same document type is selected. Deselecting the item or selecting one of another type displays the correct icon.

• Whether or not the item is selected when its replicate group window opens is inconsistent. Whenever it’s not selected the status bar “favicon” correctly displays the generic folder icon. If it’s selected and the window is in icon view then I notice the random “favicon” behavior explained above.

That first issue is cosmetic in appearance but might indicate some other problem of deeper interest. The second issue doesn’t surprise me since item (de)selection has always been quirky in different DTP contexts and I’m used to making usability adjustments for those kinds of UI unpredictability. I’ll be impressed when DTP behaves consistently enough not to have to second guess it so often. :slight_smile:

Since you’ve gotten into scripting a bit, do you think it’s possible to write one that just dumps a list of all replicated items in the database? Maybe a variant of the “Export > Listing…” script (which happens to hang when I run it on my largest database) could be hacked to do that.

In general, what I’d like (still) is a way to locate items listed in Database Properties. For instance, exactly what and where are those 1,316 Rich Texts and their 36 replicants? It’s frustrating being teased with those statistics without being able to easily find all the corresponding content. :wink:

That will be fixed in v2 when the root will be a real (but invisible) group and therefore also include meta attributes like creation/modification date etc.

Christian,

That’s good news…that will simplify scripting considerably, especially with replicants…

-e
[/quote]