Number: 569

Date: 10-Apr-84  9':38':52

Submitter: Sannella.PA

Source: jordan.pa

Subject: Proposed changes to CURSOROUTFN, CURSORINFN, and EVENTBUTTONFN

Lisp Version: 

Description: '
Date':  6 Apr 84 17':39 PST'
From': jordan.pa'
Subject': Lisp': windows and eventprops'
To': burton'
cc': lispsupport.pa, jordan.pa'
Lisp-System-Date':  1-Mar-84 14':24':22'
Machine-Type': Dorado'
'
Richard,'
'
	Following up on our discussion of windows and eventfn properties, I would like to mention the following additional observations and suggestions':'
(I am focusing on the interaction of CURSOROUTFN, CURSORINFN, and EVENTBUTTONFN).'
'
	Observations':'
  '
	1)  The triggering of CURSORIN- and CURSOROUTFN is dependent on the buttonstate of the mouse in an inconsistent manner that causes some confusion.  '
		a) If I ButtonDown in the Background and then move into window A, A''s CURSORINFN is triggered.   Remaining in this DownButtonstate until I leave A, if I'
			i)  ButtonUp in the Background, A''s CURSOROUTFN is triggered *on the Upstroke* and not when I exit the window.  '
			ii) ButtonUp in window B, A''s CURSOROUTFN is triggered, along with B''s CURSORINFN *on the Upstroke while in B*.  In this case, B''s EVENTBUTTONFN is not triggered (consistent with the belief of allowing an easy no-op option for A, I guess, although the button originally went down in the Background and not in A).'
'
		b)  Similarly, If I enter A with ButtonUp, then ButtonDown while in A and move outside A with Button still Down, (i) and (ii) also hold.'
'
	The above implies 1)  that WHEN a window''s CURSORINFN/CURSOROUTFN is triggered is dependent on the mousestate, and not always when the window is actually entered/exited, and 2)  after ButtonDowning in the Background, the first window I glide over while Down is essentially selected and committed for that stroke.'
'
	2)  Tracking the mouse with BUTTONEVENTFNs and setting global variables or FLGing via windowprops or whatever to bypass the window handler and consequences due to (1) doesn''t really help because, not being able to tell when the CURSORfns will trigger, you don''t know where you are (unless you write your own mini-windowhandler).'
'
	Suggestion':'
'
	Simply, I think the CURSOR...FNs should trigger independent of the Buttonstate of the mouse.   This would allow us to provide feedback to the user for what window the cursor is currently over, regardless of whether the buttons are up or down or how they got that way.   In particular, I should be able to UN-highlight a window when the cursor slides out because after that point (until it slides back in) a no-op will be performed, i.e., the window is UN-selected.  '
Similarly, I should be able to highlight the current window, independent of where I came from and in what Buttonstate.'
	I DO agree that BUTTONEVENTFNs should not trigger for any window anywhere outside the window in which the button went down.  This form of the no-op option appears to be the best and should stay.'
	Thus, my suggestion is to give programmers more control once a BUTTONEVENTFN is triggered, let them worry about the CURSOR...FNs side effects as the cursor slides all around the place, but do stop short of changing the feature mentioned in the previous paragraph.  '
'
	Is this possible?  I realize that if this change were made it may cause grief for a lot of existing code.'
'
Dan'
'
'
p.s.  Menus....  My assumption (as I don''t know) is that those aren''t little windows at all but boxed items highlighted by an ItemHandler a la WindowHandler under the menu''s BUTTONEVENTFN. '
'


Workaround: 

Test Case: 

Edit-By: 

Edit-Date: 

Attn: Burton.pa

Assigned To: 

In/By: 

Disposition: 

System: Windows and Graphics

Subsystem: Window System

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: 

Frequency: Everytime

Impact: Annoying

Priority: Unlikely

Status: Wish

Problem Type: Design - UI

Source Files: