Move bug in 4.0.1

[jeffcarlson]

I'm seeing a yucky bug in the 4.0.1 release. Anyone else?

1. Put cursor into a row that has rows at the same level above/below/both.

2. Press Command-Control-up arrow or Command-Control-down arrow to rearrange the row.

Expected behavior: Row should move.

Observed behavior: Row does not move.

3. Close document.

4. Open document. The order is correct.

Additional info:

Tested under OS X 10.9.1 (13B42) on a 2010 MacBook Pro 15-inch.

Tested using an existing document as well as a new document.

Choosing Organize > Move > Move Up or Move Down displays the same behavior, so it's not limited to the keyboard shortcut.

The template/style doesn't seem to matter. Seeing it in the 4-5 documents I tested.

[DerekM]

This is likely a result of fixing bugs with sorting happening too early. If you end editing it will allow you to move it correctly instead of having to re-open the file. We'll get this fixed for the next release.

[jeffcarlson]

If I understand you correctly, that means clicking the bullet to select the whole row and then moving the row. That throws a wrench into the advantage of being able to move things quickly without moving fingers from the keyboard.

(Or are you just acknowledging the bug and offering a workaround?)

[DerekM]

Yes, this is a bug. You do not have to use the mouse though, you can toggle editing with cmd-return, or the esc key if you have your prefs set to allow that.

[jeffcarlson]

Thanks!

[sven.luetkemeier]

This bug affects my workflow quite severely - any news on when a bug fix can be expected?

[Mondozer]

+1 for the effect this bug has on my workflow and eager anticipation to see it fixed.

And no, the workaround to use cmd-return to exit the edit mode has no affect on whether I can move the row either with the keyboard or the menu selection.

[DerekM]

This was fixed in 4.0.2, released on Feb 6th. If you are still seeing this behavior please contact support (mailto:omnioutliner@omnigroup.com).