Frames deselected after closing with Cmd+Return

Dorico
1

Can someone please confirm this behaviour:

  • Select a text frame that you haven’t yet modified and press Return
  • Enter text and press Cmd+Return to close the frame
  • The frame is now deselected

Immediately follow the same steps again with the same frame. This time it will remain selected.

It appears that this only happens the very first time you modify the content in a text frame. Even after you close and reopen the project, the edited frame will remain selected when closing it via Cmd+return again.

2

I’ve just tried to reproduce the behaviour you describe in Dorico Pro 5.1.70. I’ve found I can’t reproduce it. Video attached. I do remember this behaviour, though, and it was infuriating – so perhaps it has been fixed in this new release?

3

Thanks for taking the time to do this @thurulingas.

However, I’ve found the issue to be when editing frames that have been created in the Edit Page Template dialog.

Create a text frame there, apply it, and then, after closing the dialog, follow my steps from the previous post on that frame.

Editing text frames whilst in the Edit Page Template dialog works fine. Even editing newly-created text frames directly on the page itself works fine.

4

Sorry for taking so long to respond to this. Your first post didn’t mention that it was text frames created in a template that exhibited this behaviour. I’ve recreated the behaviour you described – but also tried tried finding out the boundary conditions for it.

I discovered that if you select a text frame, hit return, and immediately hit CTRL-Return, the text remains selected. It’s only after entering text that it gets deselected. But what’s actually happening seems to be that the text frames are linked, so that when editing one for the first time, Dorico assumes you are filling out text in frames throughout the project – it jumps to the next frame. But if you’re editing a frame that already contains text, that assumption no longer holds, and Dorico assumes you have further modifications to make to the same frame, and keeps it selected.

My conclusion: this is behaviour that has been put in deliberately, due to assumptions about workflows with frames that seemed reasonable to the development team.

5

Sorry, I’m not quite understanding what you’re describing.

6

It assumes that you have created lots of text frames, and wish to fill them with text sequentially. So it hops from one to the next when you hit CTRL-Enter, but only the first time through. If there’s already been a change to any given frame, the sequential approach assumption doesn’t make sense, so it keeps the frame you just modified selected in case you need to make more changes.

I’m imagining it like entering data into a spreadsheet: fill in one cell and hit return, the next cell is automatically focused. But I may be wrong, and it could just be some emergent behaviour based on the interaction of selection rules for frames. shrug

7

This isn’t what I’m concerned about - the oppposite actually.

I think it’s perfectly logical that a frame remains selected once you’ve finished editing it, allowing you to navigate to the next one. However, this isn’t happening the first time you edit a frame, only from the second time onwards. The first time, the frame is being deselected when Cmd/Ctrl+Enter is pressed.

And this behaviour is limited to frames that have been created via the Page Template editor.