Suggestions please (yes, it's me again)

[budgie]

I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

To enforce this last condition, I use a Got_Focus event and check that the cell
to the left is not vacant. If it is, I back up one cell to the left (and check
again). By this means, attempts to locate the focus to invalid locations are
defeated.

Movement within the array can result from: (a) direction arrow keys; (b) Tab
key; (c) mouse selection; or (d) Enter key. To process data entry, target cell
highlight and movement, I use Key_Press, Key_Up, Lost_Focus and Got_Focus
events.

Everything works fine *EXCEPT* that the user can't Tab outside the data entry
cells (0-7 in the example) and therefore cannot access the form's controls using
the Tab key, which isn't acceptable. I'd like the tabbing to cell 8 to result
in focus moving off the textbox array and to the first control in tab order,
rather than generating a "backup" to cell 7. Try as I might, I can't seem to
find a way to determine HOW the focus arrives at (say) cell 8 in the example.
The fact that Tab key movement is by VB and not my code doesn't help. I have
even contemplated disabling tabstop on all "invalid" cells (8-63) on the fly,
but that looks to be messy.

Any suggestions how I can determine the "history" before a Got_Focus arrival
detection so I can discriminate between the different means of arrival ?

[Geo]

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

I just tried it by only /enabling/ the first cell - then on text-change,
enabling or disabling the next index cell (depending on content of the first).
This worked - alowing normal tab action but failed (?) as I could erase the
contents of a previously occupied cell which then disabled the following. Not
sure how your rules cope with that...

Geo

[budgie]

Post by Geo

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

I just tried it by only /enabling/ the first cell - then on text-change,
enabling or disabling the next index cell (depending on content of the first).
This worked - alowing normal tab action but failed (?) as I could erase the
contents of a previously occupied cell which then disabled the following. Not
sure how your rules cope with that...

I have a check in the Lost_Focus routine which tests for an invalid value or a
blank cell, and if so it shuffles all cell contents to the right back one
position.

(BTW, the cell contents have to be numeric, in the range 0-79, and also
correspond to a valid number in another list. The presence of "0" as a valid
text value makes life interesting in some manoeuvres).

[Derek]

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.
Everything works fine *EXCEPT* that the user can't Tab outside the data entry
cells (0-7 in the example) and therefore cannot access the form's controls using
the Tab key, which isn't acceptable. I'd like the tabbing to cell 8 to result
in focus moving off the textbox array and to the first control in tab order,
rather than generating a "backup" to cell 7. Try as I might, I can't seem to
find a way to determine HOW the focus arrives at (say) cell 8 in the example.
The fact that Tab key movement is by VB and not my code doesn't help. I have
even contemplated disabling tabstop on all "invalid" cells (8-63) on the fly,
but that looks to be messy.
Any suggestions how I can determine the "history" before a Got_Focus arrival
detection so I can discriminate between the different means of arrival ?

How about using the "LostFocus" event on each control to store the
index of the control that just lost focus? That way you can use the
"GotFocus" event to compare the name and Index of the present control
with that of the last control and thus work out whether the user tabbed
there or not. if the "lostfocus" control had an index one less than the
"gotfocus" control, you could make the focus switch out of the array
otherwise have it do what it does just now.

Cheers

Derek

[budgie]

Post by Derek

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.
Everything works fine *EXCEPT* that the user can't Tab outside the data entry
cells (0-7 in the example) and therefore cannot access the form's controls using
the Tab key, which isn't acceptable. I'd like the tabbing to cell 8 to result
in focus moving off the textbox array and to the first control in tab order,
rather than generating a "backup" to cell 7. Try as I might, I can't seem to
find a way to determine HOW the focus arrives at (say) cell 8 in the example.
The fact that Tab key movement is by VB and not my code doesn't help. I have
even contemplated disabling tabstop on all "invalid" cells (8-63) on the fly,
but that looks to be messy.
Any suggestions how I can determine the "history" before a Got_Focus arrival
detection so I can discriminate between the different means of arrival ?

How about using the "LostFocus" event on each control to store the
index of the control that just lost focus? That way you can use the
"GotFocus" event to compare the name and Index of the present control
with that of the last control and thus work out whether the user tabbed
there or not. if the "lostfocus" control had an index one less than the
"gotfocus" control, you could make the focus switch out of the array
otherwise have it do what it does just now.

I'm not sure if we are on the same wavelength. A tabbing user gets "trapped" in
this array of text boxes. (Within this array,) if the G_F_index = L_F_index + 1
then the user could have arrived there by ANY of the four permissible methods.

[Derek]

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.
To enforce this last condition, I use a Got_Focus event and check that the cell
to the left is not vacant. If it is, I back up one cell to the left (and check
again). By this means, attempts to locate the focus to invalid locations are
defeated.
Movement within the array can result from: (a) direction arrow keys; (b) Tab
key; (c) mouse selection; or (d) Enter key. To process data entry, target cell
highlight and movement, I use Key_Press, Key_Up, Lost_Focus and Got_Focus
events.
Everything works fine *EXCEPT* that the user can't Tab outside the data entry
cells (0-7 in the example) and therefore cannot access the form's controls using
the Tab key, which isn't acceptable. I'd like the tabbing to cell 8 to result
in focus moving off the textbox array and to the first control in tab order,
rather than generating a "backup" to cell 7. Try as I might, I can't seem to
find a way to determine HOW the focus arrives at (say) cell 8 in the example.
The fact that Tab key movement is by VB and not my code doesn't help. I have
even contemplated disabling tabstop on all "invalid" cells (8-63) on the fly,
but that looks to be messy.
Any suggestions how I can determine the "history" before a Got_Focus arrival
detection so I can discriminate between the different means of arrival ?

Okay, I was intrigued so I had a go myself. Tabstop was the way to go
and it wasn't that messy really. Here is my test code. Save it as
FORM1.FRM and use Notepad to create a file called PROJECT.MAK with one
line in it saying FORM1.FRM. Then you can start it up using VBDOS
PROJECT1 .... but you already knew that.

-- Begin Code ----
Version 1.00
BEGIN Form Form1
AutoRedraw = 0
BackColor = QBColor(7)
BorderStyle = 2
Caption = "Form1"
ControlBox = -1
Enabled = -1
ForeColor = QBColor(0)
Height = Char(33)
Left = Char(15)
MaxButton = -1
MinButton = -1
MousePointer = 0
Tag = ""
Top = Char(3)
Visible = -1
Width = Char(63)
WindowState = 0
BEGIN CommandButton Command1
BackColor = QBColor(7)
Cancel = 0
Caption = "Close"
Default = 0
DragMode = 0
Enabled = -1
Height = Char(3)
Left = Char(23)
MousePointer = 0
TabIndex = 1
TabStop = -1
Tag = ""
Top = Char(28)
Visible = -1
Width = Char(12)
END
BEGIN TextBox Text1
BackColor = QBColor(7)
BorderStyle = 1
DragMode = 0
Enabled = -1
ForeColor = QBColor(0)
Height = Char(3)
Index = 0
Left = Char(0)
MousePointer = 0
MultiLine = 0
ScrollBars = 0
TabIndex = 0
TabStop = -1
Tag = ""
Text = ""
Top = Char(1)
Visible = -1
Width = Char(7)
END
END
OPTION EXPLICIT

CONST TRUE = (1 = 1), FALSE = NOT TRUE

DIM SHARED mFormLoaded AS INTEGER

SUB Command1_Click ()

UNLOAD Form1

END SUB

SUB Form_Load ()

DIM J AS INTEGER

LET mFormLoaded = FALSE
FOR J = 1 TO 63
LOAD Text1(J)
LET Text1(J).Left = Text1(0).Left + Text1(0).Width * (J MOD 8)
LET Text1(J).Top = Text1(0).Top + Text1(0).Height * (J \ 8)
LET Text1(J).Text = ""
LET Text1(J).TabIndex = Text1(0).TabIndex + J
LET Text1(J).TabStop = FALSE
LET Text1(J).Visible = TRUE
NEXT
LET Command1.TabIndex = Text1(63).TabIndex + 1
LET mFormLoaded = TRUE

END SUB

SUB Text1_Change (Index AS INTEGER)

IF mFormLoaded THEN
IF Index < 63 THEN
LET Text1(Index + 1).TabStop = (Text1(Index).Text > "")
END IF
END IF

END SUB

SUB Text1_GotFocus (Index AS INTEGER)

IF Index > 0 THEN
IF Text1(Index - 1).Text = "" THEN
Text1(Index - 1).SETFOCUS
END IF
END IF

END SUB

-- End Code ----

Just watch out for the normal unwanted line-splitting that the
newsreader has probably carried out. Check for badly split lines and
put them back together before running ...... but you knew that too!
Hope This Helps.

Cheers

Derek

[Derek]

Post by Derek

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

Okay, I was intrigued so I had a go myself. Tabstop was the way to go
and it wasn't that messy really.

I don't know if you want to do this or not. But if you want it to pack
the cells when a user deletes the contents of a cell other than the
last one try this modified version of Text1_Change( )

-- Begin Code ----
SUB Text1_Change (Index AS INTEGER)

IF mFormLoaded THEN
IF Index < 63 THEN
IF Text1(Index).Text = "" AND Text1(Index + 1).Text > "" THEN
LET Text1(Index).Text = Text1(Index + 1).Text
LET Text1(Index + 1).Text = ""
END IF
LET Text1(Index + 1).TabStop = (Text1(Index).Text > "")
END IF
END IF

END SUB

-- End Code ----

Cheers

Derek

[budgie]

Post by Derek

Post by Derek

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

Okay, I was intrigued so I had a go myself. Tabstop was the way to go
and it wasn't that messy really.

I don't know if you want to do this or not. But if you want it to pack
the cells when a user deletes the contents of a cell other than the
last one try this modified version of Text1_Change( )
-- Begin Code ----

(snip code)

I already have a check in the Lost_Focus routine which tests for an invalid
value or a blank cell, and if so it shuffles all cell contents to the right back
one position to maintain "contiguity" <sp?>.

[Derek]

Post by budgie

Post by Derek

Post by Derek

Post by budgie
I have a form which contains a number of controls plus an array of 64 text
boxes. The "rules" controlling the text box data entry require that cells with
data must be "left-packed" in the array, and data entry can only take place in
an occupied cell OR the first vacant cell after the contiguous block of occupied
cells. To illustrate, if cells 0-6 contain data, data entry can only take place
in cells 0-7.

Okay, I was intrigued so I had a go myself. Tabstop was the way to go
and it wasn't that messy really.

I don't know if you want to do this or not. But if you want it to pack
the cells when a user deletes the contents of a cell other than the
last one try this modified version of Text1_Change( )
-- Begin Code ----

(snip code)
I already have a check in the Lost_Focus routine which tests for an invalid
value or a blank cell, and if so it shuffles all cell contents to the right back
one position to maintain "contiguity" <sp?>.

Fair enough. I just used the Change event because that was where I was
updating the Tabstop status.

Cheers

Derek