Abdelrazak Younes ha scritto:
Why is this distinction between normal and embedded work areas needed?
Because certain operations may be meaningful only on
main/document/non-embedded
work-areas. For example, if I'm keeping the search dialog open and I
decide to open
a new document, I'd expect it to be loaded into the mainWorkArea, not
the search
one that has currently the focus. Similarly, saving the searchWorkArea
contents
may not be meaningful, or lead to unexpected results (for the normal
user, at least).
Further, when previewing, I wouldn't expect to get a preview of the
searchWorkArea,
even if I have it under focus, but I would expect a preview of the
mainWorkArea
(the document I'm working on).
I don't know exactly what else requires this distinction, but I think
there are a few
places in the code where view_.currentWorkArea() should be replaced by
view_.currentMainWorkArea().
Because the focus automatically returns to the current work area after
a dispatch. As you now make the distinction between normal and
embedded work areas, the focus goes back to the main one.
This is also strange: I do a view_.setCurrentWorkArea() in the dialog
showEvent(), so,
if at all the focus is forced to the currentWA after dispatch, it should
anyway happen
the right thing.
However, I just fixed this issue in a way that you may not like: I'm
posting a 100ms timer
activating a function that invokes searchWorkArea_.setFocus() again.
- when the dialog opens up, the searchworkarea contents is again
selected
entirely, so starting to type whatever (after a Tab for gaining
focus) deletes
the last search text
Try to set the cursor selection to false on open up
(bufferView().cursor().setSelection() or something like that).
Well, I meant this to be a feature (similar to what happens in many text
editors):
leaves you the freedom to easily modify the previous search text, or
discard it
entirely.
T.
