On iPhone finally after years simple editing of long tall entries full of pasted images stops scrolling up way off the screen when I insert an editing cursor. However, the search feature now hiding in the Sections page no longer scrolls down to a search hit I highlight. In the last version of OO3 it often failed too but if I used the Select All option, cancelled and tried again it usually worked since the initial operation seems to exposed the entries in the way manually scrolling way down does. Now the search/select operation never scrolls down, it just selects, so in super tall outlines with a couple hundred entries I have to manually scroll down to find the merely highlighted item. This completely breaks the app utility to me! I can’t quickly edit a note buried down in an outline any more. The OO2 simple search feature worked just fine, every time. It’s bizarre that simple search, the most basic feature of any word processor or outliner, gets completely broken instead of fixed after I was told a job ticket was being added for this reported bug, from your Twitter account.
Here it stays at the top of my long outline of 3D modeling notes despite my checking a search hit:
It’s also just crazy to have two toolbar icons for simply searching. The Filtering icon creates filters and then a separate tool icon invokes saved filters? That’s the weirdest interface design I’ve seen since Windows 95 shareware utilities were needed to manage files.
Can I write an API script to restore a simple search and seek (scroll down to) command? This also needs to afford full outline exposure down deep into the outline which manually scrolling is slow to activate (“loading more rows…”).
Another years old bug is that after pasting in an image, font size goes down from default 13pt to 12pt so I’m constantly having to edit back to 13pt.
My laborious new kludge is to search for an entry using the instantaneous Sections tab, then scroll down to find the needed entry and making a mental note of a unique phrase in it. I then must switch to the Filtering window search box and enter my phrase, painfully slowly as it shows no text for up to 30 seconds, often crashing instead. Then my desired entry can be edited. However I can’t see it in context of related nearby entries and if I cancel out it pops me right back to the top. This crazy cycle often also crashes my third party keyboard so badly I have to restart my phone since no keyboard at all will appear in trying to open OmniOutliner again using a password.
The ridiculous delay alone makes Filtering into a non-function. The crashing means I’m desperately seeking a new app. My outlines of project notes with images are 140-200MB but were just fine in OO2 and workable in the last OO3, as long as individual entries were not over a few screen heights tall.
I want my OO2 search command back instead of fatal computer science bloat only used by 1% of your users who understand and require object oriented Javascript which I actually do fairly well understand but have no need for in just jotting down project notes.
Some of the constant crashing and keyboard death is helped by disabling document password encryption which may be resource intensive if it has to save eneryting into a single 150MB inline file every time I make an edit. I’ve even gone back to classic Package format instead of Inline, with hope to avoid so many new entry losses when it crashes as I’m editing. That way the actual .xml file is only a couple MB with a separate folder for images. I can see these by opening a file directly from iZipPro.
Results! So when I do stop using encryption and switch back to Package format, OO becomes useable again.
Another bug is how certain entries cannot be cut/pasted since it pastes an internal link instead:
In these cases Move still works though, and restarting the app can fix it but pasting inside is blind so this isn’t a safe solution since once it pastes wrong the real entry is lost. If I’ve cut an entry and closed the document to paste into a different document, and I get this sad behaviour, restarting the app then fixes it the next time I paste the retained clipboard contents.
Irritatingly, when I do manually paste a single entry inside another, it pops that parent entry open so to scroll past it again I have to close it. This makes quick seek and organize tasks to clean up dozens of random notes rather irritating. If the user isn’t opening a triangle then let it stay closed. It pastes inside to the very end so I can’t ever see the new line anyway unless I scroll way down. Doing the same thing by using the multi select tool leaves the target entry nicely closed.
One exception to this principle of non-behavior of OO, is when I add a new blank entry below an existing long one, it fails to scroll down to it. That’s fine really but always the same scrolling down to see my new entry hassle.
Another infuriating glitch is how the latest version shows for several seconds an old cached screen view before once again showing my actual current view, every time the app is backgrounded more than a minute or so. It seems to grab the same old view like from the last time I closed a document.
What are different about the rows that do this? And you’ve only seen this happen with 3.1?
Please send any future bug reports or feature requests to us at omnioutliner@omnigroup.com. We are happy to provide answers on the forums when we can but it isn’t an official support channel. It’s also easier for the cases where diagnosing issues require sending files back and forth or involve potential personal info.
