Discussion:
New problem - interaction between control arrays (long)
(too old to reply)
budgie
2006-09-12 14:34:09 UTC
Permalink
One day, this will all be behind me and I'll look back ruefully at the hours
that I wasted on this b####y project ......

I have a form with four seperate control arrays of option buttons. The form is
used to (a) enable user configuration selection; (b) display a config determined
from a file; and (c) enable user editing of config ex a file.

The complicating factor is that the selections interact, and they have to. For
example, in the first array of two choices, selecting the second button is
required to invalidate the first and last selection in the second array (five
buttons). Any selection in the second array must invalidate at least one of the
four selections in the fourth array, which one depending on the selection in the
second array. Any selection (one of six) in the third array will dicate which
fourth array element is TRUE. So there are four Option_Click event routines
which ensure the logic is complied with.

(This isn't an exercise or a game, it is implementing a real world requirement.
All this interaction was quite *fun* to program, and works fine when I enter the
form for user data entry.)

However, when a configuration is determined from a file and I try to load this
information into the arrays for user view/edit, all hell breaks loose. My code
correctly determines which buttons are selected and disabled in each array. But
in setting values to TRUE in the decoding module, these _Click events are
triggered and it is like a cartoon ball ricocheting around a small room - there
are no less than TWELVE invocations of these _Click routines before a stable
configuration is achieved. And when the dust has settled, I see:
-> selection of disabled ("greyed out") options; and
-> invalid combinations

If I exit the form ("Cancel") and re-enter, the correct data* is shown. But
that is obviously not the way it ought to work.

If I re-order the blocks of code which determine and set TRUE the various array
options, the sequence of ball bounces (_Click event invocations) is different
but the overall result is the same.

If setting values to TRUE didn't trigger the _Click events, I'd he home and
hosed, but that's not how VB works. I've even tried using a Form_Load event to
effectively represent the secong call to the form, but can't make any headway.

Sorry for being so long-winded, but this one really has worn me to a frazzle.
I'd welcome any constructive suggestions. Please.

---------------------------------------------------------
* the third array data is ambiguous if determined from other arrays - either of
two values can match any selection in the other three arrays, but a selection in
this array has unique meaning and translates into a unique combination in the
other areas. So when the third array data is derived rather than user (or file)
selected, my code selects the lower of the two corresponding option indexes.
alpine
2006-09-12 15:26:39 UTC
Permalink
It sounds to me like you need to create a module level flag that
indicates that you are loading values before displaying the dialog and
skip all of the code in the click events when the flag is set.
Something like....

' general section of the form module
Private m_bIsLoading As Boolean


' form load event
Private Sub Form_Load()

m_bIsLoading = True

' load your settings from file

m_bIsLoading = False

End Sub


' in the click events
Private Sub optWhatever_Click(Index As Integer)

If m_bIsLoading = False
' run your logic here

End if

End Sub


HTH,
Bryan
_________________________________________________________
Bryan Stafford "Don't need no more lies"
New Vision Software - Neil Young -
www.mvps.org/vbvision Living With War : The Restless Consumer
Post by budgie
One day, this will all be behind me and I'll look back ruefully at the hours
that I wasted on this b####y project ......
I have a form with four seperate control arrays of option buttons. The form is
used to (a) enable user configuration selection; (b) display a config determined
from a file; and (c) enable user editing of config ex a file.
The complicating factor is that the selections interact, and they have to. For
example, in the first array of two choices, selecting the second button is
required to invalidate the first and last selection in the second array (five
buttons). Any selection in the second array must invalidate at least one of the
four selections in the fourth array, which one depending on the selection in the
second array. Any selection (one of six) in the third array will dicate which
fourth array element is TRUE. So there are four Option_Click event routines
which ensure the logic is complied with.
(This isn't an exercise or a game, it is implementing a real world requirement.
All this interaction was quite *fun* to program, and works fine when I enter the
form for user data entry.)
However, when a configuration is determined from a file and I try to load this
information into the arrays for user view/edit, all hell breaks loose. My code
correctly determines which buttons are selected and disabled in each array. But
in setting values to TRUE in the decoding module, these _Click events are
triggered and it is like a cartoon ball ricocheting around a small room - there
are no less than TWELVE invocations of these _Click routines before a stable
-> selection of disabled ("greyed out") options; and
-> invalid combinations
If I exit the form ("Cancel") and re-enter, the correct data* is shown. But
that is obviously not the way it ought to work.
If I re-order the blocks of code which determine and set TRUE the various array
options, the sequence of ball bounces (_Click event invocations) is different
but the overall result is the same.
If setting values to TRUE didn't trigger the _Click events, I'd he home and
hosed, but that's not how VB works. I've even tried using a Form_Load event to
effectively represent the secong call to the form, but can't make any headway.
Sorry for being so long-winded, but this one really has worn me to a frazzle.
I'd welcome any constructive suggestions. Please.
---------------------------------------------------------
* the third array data is ambiguous if determined from other arrays - either of
two values can match any selection in the other three arrays, but a selection in
this array has unique meaning and translates into a unique combination in the
other areas. So when the third array data is derived rather than user (or file)
selected, my code selects the lower of the two corresponding option indexes.
Bob O`Bob
2006-09-12 17:23:39 UTC
Permalink
Post by alpine
It sounds to me like you need to create a module level flag that
indicates that you are loading values before displaying the dialog and
skip all of the code in the click events when the flag is set.
Something like....
I agree.

When I saw that you'd already followed up, I wondered if you might have
a substantially different suggestion from mine, but no, you covered it already.

Some day I may just dig out VBDOS again, if only for a laugh.
Obviously has limited use these days, but in those few situations
not much else could come close.


Bob
--
A***@NOT.AT.Arargh.com
2006-09-12 18:43:24 UTC
Permalink
On Tue, 12 Sep 2006 10:23:39 -0700, Bob O`Bob
Post by Bob O`Bob
Post by alpine
It sounds to me like you need to create a module level flag that
indicates that you are loading values before displaying the dialog and
skip all of the code in the click events when the flag is set.
Something like....
I agree.
When I saw that you'd already followed up, I wondered if you might have
a substantially different suggestion from mine, but no, you covered it already.
Some day I may just dig out VBDOS again, if only for a laugh.
Obviously has limited use these days, but in those few situations
not much else could come close.
And I was going to suggest the same thing. :-)
--
ArarghMail609 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
John Kane
2006-09-13 10:13:58 UTC
Permalink
Post by A***@NOT.AT.Arargh.com
And I was going to suggest the same thing. :-)
Me too, but I would create one procedure for doing all the logic,
setting the flag at the beginning and unsetting it at the end. Then call
this procedure from each Opt_Click if the flag is not set.
--
Regards, John
***@johnkane.clara.co.uk
budgie
2006-09-13 14:50:40 UTC
Permalink
Post by budgie
One day, this will all be behind me and I'll look back ruefully at the hours
that I wasted on this b####y project ......
Thanks to Bryan, Bob and John for responding in one voice. Feels great when
there is consensus like this.

I implemented your suggestion by inserting a line:

IF NOT xxxx THEN EXIT SUB

as the first executable in each click event, where xxxx is the flag.

What I now have is:
(a) If I enter the problem form (frmDefType) from the main menu ("cold start",
default selections made in the SUB that SHOWs the form, and whose last statement
before the SHOW sets the flag to TRUE, the interactions within the form's option
button control arrays (OBCA) still work fine BUT ....
each of the four _Click events is called once before the form appears.

(main)

CASE 10
CALL GetType
....

(SUB GetType)

IF NOT xxxx THEN
(sets 4*default OB VALUE=TRUE)
ENDIF

xxxx = TRUE
Post by budgie
breakpoint
frmDefType SHOW

END SUB

It reaches the breakpoint OK, no spurious events, but before the form DefType
appears there is one call to each _Click event.

(b) the decode_and_pre-load routine preloads OK without the unwanted _Click
events, but as soon as I select the show/edit menu selection CASE 10 again, I
get SIX _Click events and default values are displayed, not the decoded ones.
Exiting and reselecting this CASE 10 option no longer get the proper values to
appear.

The key here seems to be that despite inhibiting the Click events during
pre-loading values, VB-DOS seems to store a memory of the call (similar to KEY
STOP in QB & here in VB-DOS) and invoke it when released. If that is indeed
what is happening, this inhibiting is only a partial cure. Comments welcome.
A***@NOT.AT.Arargh.com
2006-09-13 20:19:50 UTC
Permalink
Post by budgie
Post by budgie
One day, this will all be behind me and I'll look back ruefully at the hours
that I wasted on this b####y project ......
Thanks to Bryan, Bob and John for responding in one voice. Feels great when
there is consensus like this.
IF NOT xxxx THEN EXIT SUB
as the first executable in each click event, where xxxx is the flag.
(a) If I enter the problem form (frmDefType) from the main menu ("cold start",
default selections made in the SUB that SHOWs the form, and whose last statement
before the SHOW sets the flag to TRUE, the interactions within the form's option
button control arrays (OBCA) still work fine BUT ....
each of the four _Click events is called once before the form appears.
(main)
CASE 10
CALL GetType
....
(SUB GetType)
IF NOT xxxx THEN
(sets 4*default OB VALUE=TRUE)
ENDIF
xxxx = TRUE
Post by budgie
breakpoint
frmDefType SHOW
END SUB
It reaches the breakpoint OK, no spurious events, but before the form DefType
appears there is one call to each _Click event.
(b) the decode_and_pre-load routine preloads OK without the unwanted _Click
events, but as soon as I select the show/edit menu selection CASE 10 again, I
get SIX _Click events and default values are displayed, not the decoded ones.
Exiting and reselecting this CASE 10 option no longer get the proper values to
appear.
The key here seems to be that despite inhibiting the Click events during
pre-loading values, VB-DOS seems to store a memory of the call (similar to KEY
STOP in QB & here in VB-DOS) and invoke it when released. If that is indeed
what is happening, this inhibiting is only a partial cure. Comments welcome.
If MS had released the source to the VBDOS runtime, it might be
possible to find out what is happening. I am not sufficiently
interested in VBDOS to take several days to deassemble the RTL and
several months to figure out what is happening. Sorry.
--
ArarghMail609 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Bob O`Bob
2006-09-13 21:41:31 UTC
Permalink
Post by budgie
The key here seems to be that despite inhibiting the Click events during
pre-loading values, VB-DOS seems to store a memory of the call (similar to KEY
STOP in QB & here in VB-DOS) and invoke it when released. If that is indeed
what is happening, this inhibiting is only a partial cure. Comments welcome.
I don't know what is happening, but I'm fairly certain that it's NOT like that.
And even if it is, careful use of DoEvents should fix it.


I was unable to follow your description of how you implemented the flag logic.
I therefore have to suspect that it was incomplete.



Bob

Loading...