RE: sendEvent: disable/enableFlushWindow & _handleWindowNeedsDisplay:

[David Ayers]

This is a tough one...

OK. I'm back to making NSTextView (as the deepest possible object)
responsible for the disable/enableFlushWindow. It's also the object that
interacts with NSPastboard. Eventhough NSPasteboard actually sends the DO
message to the pasteboard server, therefore implicitly reruning the runloop,
it surely doesn't have any knowledge of any window or view or display
mechanism. So NSTextView might disable/enableFlushWindow. (This was also my
original approach, except I had reset setViewNeedsDisplay: instead of using
disable/enableFlushWindow.) So now my approach looks something like:

NSView.h:

+#define GS_VIEW_DISABLEFLUSHWINDOW [_window disableFlushWindow];NS_DURING;
+#define GS_VIEW_ENABLEFLUSHWINDOW  NS_HANDLER;[_window
enableFlushWindow];[localException raise];NS_ENDHANDLER;[_window
enableFlushWindow];

NSTextView.m:

 /** Extension method that copies the current selected text to the
     special section pasteboard */
 - (void) copySelection
 {
+  GS_VIEW_DISABLEFLUSHWINDOW
   [self writeSelectionToPasteboard: [NSPasteboard pasteboardWithName:
@"Selection"]
        type: NSStringPboardType];
+  GS_VIEW_ENABLEFLUSHWINDOW
 }

 /** Extension method that pastes the current selected text from the
     special section pasteboard */
 - (void) pasteSelection
 {
+  GS_VIEW_DISABLEFLUSHWINDOW
   [self readSelectionFromPasteboard: [NSPasteboard pasteboardWithName:
@"Selection"]
        type: NSStringPboardType];
+  GS_VIEW_ENABLEFLUSHWINDOW
 }


NSWindow.m:

 - (void) _handleWindowNeedsDisplay: (id)bogus
 {
+  if (_disableFlushWindow)
+    {
+      [[NSRunLoop currentRunLoop]
+         performSelector: @selector(_handleWindowNeedsDisplay:)
+                 target: self
+               argument: nil
+                  order: 600000
+                  modes: [NSArray arrayWithObjects:
+                                  NSDefaultRunLoopMode,
+                                  NSModalPanelRunLoopMode,
+                                  NSEventTrackingRunLoopMode, nil]];
+    }
+  else
+    {
       [self displayIfNeeded];
+    }
 }

These macros could be used anywhere a view implicitly reruns a runloop. Yet
this doesn't have the "transaction" or "atomic function" semantics of my
last approach.

Approach 1(a): The view object (method), which will implicily rerun the loop
takes care not let the VIEW display itself by setting it's setNeedsDisplay:
to NO while calling the methods which will rerun the runloop.
Drawback - if multiple views implicitly rerun the runloop (call selectText:)
with in a method, each call after the first one will cause the views which
had just avoided drawing during thier own selectText: will be drawn.

Approach 1(b): The view object (method), which will implicily rerun the loop
takes care not let the WINDOW display the selection by setting it's
disableFlushWindow while calling the methods which will rerun the runloop.
Merrit   - Multiple calls to selectText: (or rather reruns of the runloop)
won't cause the views to display.
Drawback - Multiple views OF DIFFERENT WINDOWS that implicitly rerun the
runloop (call selectText:), will cause the views to be displayed.

Approach 1(c): Introduce a new disable/enableDisplay mechanism which is
analogous to disable/enableFlushWindow yet applies to all display.
Merrit   - fixes drawbacks of 1(a) and 1(b)
Drawback - Introduces another level of complexity which has to be used in
many different places.

Approach 2: Attempt to enclose the view manipulations within "View
Manipulation Transactions". I'm not clear on how to do this correctly. In my
current case this "Transaction Context" would have been in sendEvent:
starting before it makes the view first responder (calling selectText: in
the future) and ending after invoking mouseDown:. It's just to bad that
Scrollers (and probably other dragging events) repoll events before
returning from mouseDown: so windows wouldn't be updated until the scrolling
(or dragging) ended and mouseDown: returns.

Approach 3: Find out why the
performSelector:@selector(_handleWindowNeedsDisplay:)... is actually needed
in the first place and try to find a different solution.

I'm starting to lean heavily towards Approach 3.

Thoughts, Suggestions, Anyone?
Dave