The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniOutliner > OmniOutliner 3 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
.oo3 suffix means crippled file? Thread Tools Search this Thread Display Modes
First let me rave about OmniOutliner Pro: it is revolutionizing my file system, due to its flexibility and its linking capability. Finally an app powerful enough to take over from my old AppleWorks outlines. Or at least I thought so until this morning.

I'm using OOP 3.8 beta 1 on a PowerPC G4 running Mac OS 10.5.5. I'm trying to reproduce a problem I had earlier this morning.

In OOP file A I make a link to OOP file B by dragging in file B's icon from Finder; the link button is labeled with only the name of file B, with no suffix. I save file A. I open file B from the link in File A; file B comes up with the suffix ".oo3". In file B I make a change, save the file and close it. Then I open file B again from file A (which was open the whole time). The change to File B is there.

BUT when I go to finder and click on file B, it comes up in a third window, without the suffix, and without the change.

This defeats the whole purpose of linking: when I go to the other file, I want to be able to modify it! Does that .oo3 suffix indicate some kind of crippled, surrogate file?

This problem reminds me strongly of a problem I had in an earlier version of OOP. I didn't document that one very well, so can't really compare. But I haven't had the problem in some time, and I make these kinds of links frequently.

The problem started today when I did something slightly different from the description above. Let's see how well I can remember it:

Last night in OOP file A I made a link to OOP file B by dragging in file B's icon from Finder. I don't remember whether the link button had the suffix or not. I don't remember whether I saved file A (but it's likely, I save very often). I opened file B; probably from the link in File A but I'm not sure. I made extensive changes File B. Then my fingers slipped and I wasn't sure what had happened, so I saved file B as "file Boop" and opened file B beside it to compare. (Long before I started using OmniOutliner I formed the habit of doing this "oops" procedure; the addition of "oop" to the file name refers to that, not to the name of the app.) The new file was fine; to preserve all the work I'd made on it, I closed file B and saved File Boop as File B, then closed the file. I also saved and closed file A, then in Finder deleted file Boop.

This morning I opened OmniOutliner without a file, then opened File A from Recent Files. Then I opened file B, but I don't remember how. Drat! it's all getting fuzzy now. What I do recall is that at some point I had two different versions of file B open: one with all the changes I'd made yesterday, and one completely without. This was the first time the problem had recurred since I'd installed the latest beta.

I sure hope you can make it possible to modify OOP files accessed via OOP links.

-- Catherine
 
After I posted the above report, the links from one OOP file to another started getting even weirder.

I reinstalled OOP and now they appear to be working again.
 
OmniOutliner by default will embed the file when you drag and drop it into the outline. If you drag and drop a folder, or hold down the control key when dragging and dropping a file, you will get a link which will go to the item instead of pulling the (possibly stale) data out of the OmniOutliner file. It sounds like you are using OmniOutliner as a file organizing tool, and for that you'll definitely want to do the control key trick when attaching files.

The OmniOutliner help for "attach file" covers this material well. You were embedding copies of the files in your outline, so when the external file changed, you didn't see the changes (and clicking on the external file in the finder took you to a different place).
 
By the way, as I notice you are also an OmniFocus user -- the default behavior in OmniFocus is the opposite. There, if you drag a file, you get the alias that you wanted here, and you have to take extra steps if you really want to embed the file in the database. A bit confusing, perhaps, but with some thought it makes sense. In OmniOutliner, you are probably intending to take all that data with you if you move the outline to another machine, so you would prefer (for most cases, admittedly not yours) to embed the files. In OmniFocus, where you may be syncing the file to a mobile device with limited capacity (cpu, storage, and ability to open arbitrary file types), most of the time you don't want the files embedded. Each program is optimized to make what is expected to be the more usual case easier.
 
Isn't it the Option key that reverses this behavior, at least in OmniFocus? Unfortunately, I am unable to test it at the moment.

-Dennis
 
Quote:
Originally Posted by Toadling View Post
Isn't it the Option key that reverses this behavior, at least in OmniFocus? Unfortunately, I am unable to test it at the moment.

-Dennis
From the OmniOutliner online help:

Quote:
If you attach a folder, or hold the control key while dropping a file, an alias (a "link") to the file or folder will be created instead.
The option key does it in OmniFocus, as you state.
 
Quote:
Originally Posted by whpalmer4 View Post
OmniOutliner by default will embed the file when you drag and drop it into the outline. If you drag and drop a folder, or hold down the control key when dragging and dropping a file, you will get a link which will go to the item instead of pulling the (possibly stale) data out of the OmniOutliner file.
This explains most of the OOP behavior in this problem.

Quote:
It sounds like you are using OmniOutliner as a file organizing tool.
Yes. And now that I understand what's going on, it's a powerful one.

Quote:
The OmniOutliner help for "attach file" covers this material well.
It does. However I couldn't find it until you mentioned it, because I was looking for "link" or "linking" in help. Could a reference be added under that term?

Many thanks for clearing this up!
 
Quote:
Originally Posted by CatherineHC View Post
This explains most of the OOP behavior in this problem.
If you can tell me which behavior it doesn't explain, I'll try to cover that as well :-)
Quote:
However I couldn't find it until you mentioned it, because I was looking for "link" or "linking" in help. Could a reference be added under that term?
Yes, but not by me! Use Help->Send Feedback inside the application, or email omnioutliner@omnigroup.com to suggest this. Unfortunately, I think there are some issues with internationalization (I don't recall the precise details) that make some seemingly trivial documentation changes not so trivial to implement.

When I do a help request for "link" I do get the pages for Embedding files vs. creating aliases and Attaching files to an outline as the 3rd and 4th hits.
 
Quote:
Originally Posted by whpalmer4 View Post
If you can tell me which behavior it doesn't explain, I'll try to cover that as well
The still-unexplained behavior is how the links got "weirder." In testing the linking/attaching feature today, I have at least partly replicated that weirdness.

I use a Cirque EasyCat touchpad. If I press the Control key on my keyboard before I touch the trackpad, it just brings up a contextual menu. I now start creating a proper link (not an embedded file) in OOP by clicking on the Finder icon and dragging it toward its intended location in OOP. Before I drop it, I press the Control key too.

When the file I'm linking is an AppleWorks file, I have to hold the control key down until after I drop the icon into OOP. If I let up the Control key before I let up pressure on the trackpad, I get a button made in OOP that brings up an attached file (not the original) with a title like this: 1_#$!D@%!#_Doctors upd#A$C$BA (WP).

When the file I'm linking is an OOP file, it doesn't matter when I let up the control key. I haven't tried linking any other applications's files yet -- and don't have time for any more testing right now. If it's just AW that does this, it's no problem: I'm using OOP to replace all my old AW files anyway, because AW has started losing data on me. (OOP is more powerful; I like my new file management system better -- but I wouldn't have started this pain-in-the-neck conversion from AW to OOP if I didn't have to get rid of AW.)

The garbage title on the AW file embedded with early release of the control key... looks very familiar: that's what I saw last week when the "weirdness" started. But.... though I didn't record what was happening then, it's highly unlikely I used the control key at all.

Thanks for instructions how to submit suggestions to Help.

Quote:
When I do a help request for "link" I do get the pages for Embedding files vs. creating aliases and Attaching files
Ah, yes: I see it now. So much for my ability to notice what I'm looking at.

Thanks for all your help, and for a great product.
Attached Thumbnails
Click image for larger version

Name:	link help.jpg
Views:	578
Size:	18.9 KB
ID:	859  

Last edited by CatherineHC; 2009-02-02 at 07:48 AM..
 
Quote:
Originally Posted by Toadling View Post
Isn't it the Option key that reverses this behavior, at least in OmniFocus? -Dennis
Dennis, I tried using the Option key. It had no effect on the linking/attaching process.

Thanks for the suggestion, anyway.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
prefix/suffix on numbering steve OmniOutliner 4 for Mac 1 2013-05-08 12:31 AM
sp6: easier means to remove autofill data earthsaver OmniWeb Feature Requests 2 2006-04-27 10:14 PM


All times are GMT -8. The time now is 10:04 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.