To: strang at frc at grid1 From: Bey@Development@GRiD Sender: Bey@Development@GRiD Subject: Re: 91109033 PADSOFT Date sent: 11/10/89 10:00 AM In reply to the message of 11/9/89 7:11 PM from PARs@Development@GRiD If you are checking for lstChangedEvents in your application, you MUST check for this type of event BEFORE you pass the event to FrmHandleEvent. This also is true for ctlEnterEvent, fldEnterEvent, and lstEnterEvent. This is documented in Chap. 6 of the GRiDPAD Program Dev. Manual (9/89). If you check for the event after passing it to FrmHandleEvent, it's true, the choice index could be off by one. This quirk is inherent to the design of the system. See Art for more details. Christopher -------------------------------------------- To: pars at development Sender: Strang AT FRC@GRiD1 Subject: gridpad api Date sent: 11/2/89 10:08 AM Class: 2 Copies: lamb at development Product: GRiDPad API Version #: 89.9.22 Problem summary: lstChangedEvent data3 value isometimes incorrect Details: The data3 of a lstChangedEvent is supposed to be the index of the new list choice selected. Instead, under certain circumstances it appears to be the index of the list choice just unselected, meaning the previous list choice. This happens when the choice box is dragged up and down a list without releasing the mouse button. The data3 of the lstChangedEvents produced always lags one behind the actual position of the choice box. When the mouse button is released, a lstChangedEvent with the correct index is produced. If I call LstGetCurrentChoice when I get the event, it always returns the correct index. Priority: 1 Request response? N Hardware Configuration Computer & model: GRiDCase 1530 w/387, 2MB RAM Peripherals: Internal 40MB, external 3401, MS mouse Server: Software Configuration MS-DOS: 3.21 BIOS: 7/25/88 Additional comments: 386 to the Max: 4.05To: Strang@FRC@GRiD1 From: Cassidy@Development@GRiD Sender: Cassidy@Development@GRiD Subject: Re: par on lstChangedEvent Date sent: 11/10/89 08:28 AM In reply to the message of 11/9/89 7:11 PM from PARs@Development@GRiD Perhaps you have already talked to Art about this and had it explained, but in case you haven't let me say that I ran into the same problem a while back and would be gald to explain my understanding of things if you're interested. Art's contention is that this is not a bug, but rather a misunderstanding by users of how FrmHandleEvent works. When this function is called with the mouse button down, it doesn't return to the application until the mouse button is released. For more details, give me a call at (415) 656-1661 X253. Rion Cassidy -------------------------------------------- To: pars at development Sender: Strang AT FRC@GRiD1 Subject: gridpad api Date sent: 11/2/89 10:08 AM Class: 2 Copies: lamb at development Product: GRiDPad API Version #: 89.9.22 Problem summary: lstChangedEvent data3 value isometimes incorrect Details: The data3 of a lstChangedEvent is supposed to be the index of the new list choice selected. Instead, under certain circumstances it appears to be the index of the list choice just unselected, meaning the previous list choice. This happens when the choice box is dragged up and down a list without releasing the mouse button. The data3 of the lstChangedEvents produced always lags one behind the actual position of the choice box. When the mouse button is released, a lstChangedEvent with the correct index is produced. If I call LstGetCurrentChoice when I get the event, it always returns the correct index. Priority: 1 Request response? N Hardware Configuration Computer & model: GRiDCase 1530 w/387, 2MB RAM Peripherals: Internal 40MB, external 3401, MS mouse Server: Software Configuration MS-DOS: 3.21 BIOS: 7/25/88 Additional comments: 386 to the Max: 4.05