New problem - interaction between control arrays (long)

budgie · Joined: 04 Oct 2007 Posts: 40

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.

Archived from group: microsoft>public>vb>dos

alpine · Joined: 04 Oct 2007 Posts: 620

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
alpineDon'tSpam@mvps.org

On Tue, 12 Sep 2006 22:34:09 +0800, budgie wrote:

>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.

Bob O`Bob · Joined: 04 Oct 2007 Posts: 1456

alpine wrote:
> 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
--

ArarghMail609NOSPAM · Joined: 04 Oct 2007 Posts: 2

On Tue, 12 Sep 2006 10:23:39 -0700, Bob O`Bob
wrote:

>alpine wrote:
>> 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. Smile

--
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 · Joined: 04 Oct 2007 Posts: 9

In article ,
ArarghMail609NOSPAM@NOT.AT.Arargh.com says...
>
> And I was going to suggest the same thing. Smile

>

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
news@johnkane.clara.co.uk

budgie · Joined: 04 Oct 2007 Posts: 40

On Tue, 12 Sep 2006 22:34:09 +0800, budgie wrote:

>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
>>> 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.

ArarghMail609NOSPAM · Joined: 04 Oct 2007 Posts: 2

On Wed, 13 Sep 2006 22:50:40 +0800, budgie wrote:

>On Tue, 12 Sep 2006 22:34:09 +0800, budgie wrote:
>
>>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
>>>> 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 · Joined: 04 Oct 2007 Posts: 1456

budgie wrote:

> 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