I missed the first part of this thread, so I don't know exactly what you
want to do, but from the sound of things, couldn't you take a look at the
script generated by insert+tab. Somewhere jfw knows which element you are
on and how many elements there are in the list.
Bob
----- Original Message -----
From: Dennis Brown <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 19, 1999 5:31 PM
Subject: Re: Changing JFW's Listview behaviour
> Hello Derek,
>
> No, you'd get the same results as checking the row position, and for the
> same reason; the BottomEdgeEvent is the bottom edge of the window, and as
I
> stated before, a listbox window stops at the bottom of the screen and the
> contents scroll up from there, so the bottom of the window isn't the
bottom
> of the list.
> Thanks,
> Dennis Brown, [EMAIL PROTECTED]
>
> ----- Original Message -----
> From: Derek Lane <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 19, 1999 10:13 AM
> Subject: Re: Changing JFW's Listview behaviour
>
>
> > What about the bottom edg event function.
> > ----- Original Message -----
> > From: Dennis Brown <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, July 19, 1999 11:55 AM
> > Subject: Re: Changing JFW's Listview behaviour
> >
> >
> > > Hi Jonathan,
> > > Yes, you can, but it causes such a delay in the movement keys,
> > > UpArrow/DownArrow, that it isn't worth it--but I'm still working on
it!
> > > The delay comes with having to do the following sequence with each
press
> > of
> > > the direction keys:
> > > 1) Get current position/item info and store it in a variable. In
this
> > > example, we'll call this variable "CurrentLocation".
> > > (Functions available: GetWord/GetLine, GetCursorPosition,
GetCursorCol,
> > > GetCursorRow).
> > > 2) Move in the desired direction with the Up/Down arrow.
> > > 3) Read the new line.
> > > 4) Compare the new position/item with the previous line's info in
> > > CurrentLocation variable.
> > > (Functions available: same as in step#1 to retrieve the new info,
then
> a
> > > simple "If/Then" statement to test the new info.
> > > "If NewInfo == OldInfo Then...)
> > > 5) If it matches, then you've reached a boundary, so read the line
> again,
> > > or have it announce a boundary message, (i.e. "Top" or "Bottom").
> > > (so if it isn't the same, then continue...)
> > > If not the same, start at item#1 and save the current position/item in
> the
> > > CurrentLocation variable, replacing the previous location info, and
> > process
> > > the whole set again.
> > >
> > > The delay is needed between moving to the new position/item, and
> comparing
> > > the new data to the old data. Without the delay, it sometimes doesn't
> > give
> > > JFW time to fully focus on the new item, causing it to compare the
> > previous
> > > item with the previous item, and giving the false notification that
you
> > have
> > > reached a boundary!
> > > You've also got to check that you are indeed in some type of list
before
> > > letting the process execute--you wouldn't want it to do this in an
edit
> > box,
> > > or dialog, etc.
> > >
> > > I've tried just checking the current cursor row with the previous
cursor
> > > row, (with the GetCursorRow), and if it didn't change, that would
> indicate
> > > that the item you are on is the first or last item in the list. The
> > problem
> > > was quickly noticed when a list had more items than could fit on a
> single
> > > screen; when scrolling a list down beyond the current screen within a
> > > list-type control, the cursor stops at the bottom of the screen, and
the
> > > list scrolls up to bring the next screen's items into focus! So the
> > cursor
> > > row stopped at that location, even though items still scrolled up!
> > > Since testing the position won't work, I then compared the list's
> current
> > > item with the previous item, and without using some delay function to
> give
> > > JFW time to focus on the new item, it would constantly compare the
> > previous
> > > item with the previous item, since that current item was retrieved
with
> > the
> > > GetWord, GetLine, GetField, etc., before focus moved from the previous
> > item!
> > >
> > > My hopes are that a future JFW does this at a lower level, possibly
> > > accessing the needed info within the control itself, possibly checking
> the
> > > index of the list before the data output, detecting whether the output
> is
> > > the same with previous output.
> > > I'm still working on it though!
> > > Thanks,
> > > Dennis Brown, [EMAIL PROTECTED]
> > >
> > >
> > > ----- Original Message -----
> > > From: Jonathan Mosen <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Sunday, July 18, 1999 6:45 PM
> > > Subject: Changing JFW's Listview behaviour
> > >
> > >
> > > > Hi folks. I wonder if any of you script experts have some thoughts
on
> > the
> > > > following.
> > > >
> > > > If you use the up or down arrow keys in say an edit control or rich
> > edit,
> > > > JFW will ding and speak the last or first line. If you do this in a
> list
> > > > view or list box, JFW says absolutely nothing at all. Is there any
way
> I
> > > can
> > > > change this so that when up or down arrowing, JFW repeats the first
or
> > > last
> > > > line respectively in a list control?
> > > >
> > > > Jonathan Mosen
> > > > Listen to MBSFM with the best music from the last four decades
> > > > http://www.mbsfm.com
> > > > -
> > > > Visit the jfw ml web page: http://jfw.cjb.net
> > >
> > > -
> > > Visit the jfw ml web page: http://jfw.cjb.net
> >
> > -
> > Visit the jfw ml web page: http://jfw.cjb.net
>
> -
> Visit the jfw ml web page: http://jfw.cjb.net
>
-
Visit the jfw ml web page: http://jfw.cjb.net
