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
