Dealing with updating lots of controls

[Bad_Syntax]

I'm pretty experienced, so I am not looking for any code.

What I am looking for is methods or tricks to help with avoiding infinite recursions on form updates.

For example, lets say I'm building a tank with a form.

I have a dropdown for the weight
I have a dropdown for the mobility type (tracks or wheels)

So I have an event for the value change of weight, which updates the mobility type (too heavy means no wheels).
I also have an event for the value change of the mobility type, selecting wheels means weight will be limited to maybe 30 tons.

If you update the weight, it'll update the mobility, which then updates the weight = infinite recursion.
If you update the mobility, it'll update the weight, which then updates the mobility = infinite recursion.

I've tried all sorts of things, like saving a variable saying "updating" that'll just exit the subs whenever they are called, but when I have 30 or more of these little dropdowns, each modifying maybe a dozen others, it gets to be a real PITA and I end up running thousands of updates for somebody changing a single dropdown.

Some of my other ideas was a timer that did all the updates and not use changed events at all, but it gets weird. I've also thought about creating a class that completely recreates the values of all comboboxes on the form each time any value is updated, but that doesn't feel right.

I end up doing a lot of apps like this, and they always end up killing me as I'm just not "getting something". I've been coding in VB for about 13-14 years, but have never once worked with any other programmers (mostly a hobby, but I have produced lots of things at work too, just never part of a team). Based on that I'm sure I'm just not learning some key things that you would learn when working with teams.

With just a couple dropdowns its easy, but when I have so many of those that all link to various others, well, its not good.

Any ideas on how I can better do updates to forms without calling the same functions over and over?

 

[VBobCat]

When dealing with situations like these, I think it's better if user's choices are considered as a whole, and not field-by-field.
That leads to setting the form code not to handle such many events, but simply store user's choices. Just when user clicks a button called "process" (or something meaningful), then fetch all those choices in an algorythm that tells user if the chosen conditions are allowed, and, if they aren't, why is that so.
Other possibility is to map all the choices' consequences, group them in blocks of items that affect each other, and provide collective treatment for each block.
In any case, you must first have a set of features defined by the user, and then make a validation.
This is a general consideration, but I hope sincerely it helps.

 

[Bad_Syntax]

I think my issue then is I try to avoid showing users invalid choices. If they make a selection that removes possibilities, I don't display those impossible options to make it easy on the user. Also, I use external data files to build these choices so they are kept dynamic and easy to update, meaning I can't really hard-code anything.

Perhaps I'm just not designing the form interaction enough before I start coding.

If only there was a way when I change the selected index, if there was an option to not do any other event changes outside of the function that called it.

Thanks for the input.

 

[VBobCat]

Yes, I know what you mean, I had such problems lots of times.

What I learned from this experience is to have as clearer as I can the tree of decisions, so that I can design an interface where the user must start making the most antecedent decisions which will define what he will have, making clear that if he changes his idea, he must start all over.

I do it this way: I handle together the events of a group of higher level, co-dependent and antecedent set of comboxes. Each combination of their settings will reset the datasource property of the lower-level comboboxes (and an incomplete or invalid combination will disable them so the user can't even continue making choices whithout correcting his previous choices to provide a valid combination of preconditions) with an "on-the-fly" query that is defined by those combination.

When I'm done, the decisions are made in a step-by-step mode, even if all the controls are on the same form (in this case, I try to arrange them in a top-down set of priority).

I think you are right on this: you must avoid showing users invalid choices. My choice for that is disabling the following controls, so the user knows he can't go further unless he fix the mess he's made.

In my experience, users won't necessarily follow any reasoning when filling out the forms. And they will never, ever replicate the reasoning of the program. People are quite chaotic. Interface and code must fence them in as much as possible towards the logic sequence of choices. At least, my apps' users do so, they act as if they were drunk or worse. I hope your users behave better

So, good luck!

 

[IanRyder]

Hi,

I have just joined the forum and saw your post.

Have you tried removing the event handler of the controls your updating so that they do not cause your infinite recursion issue? After you have completed the update of the controls you are working with then just Re-Add the event handlers to each control?

Hope this helps.

 

[Herman]

I second IanRyder's suggestion. I usually try to write my apps to avoid having to use recursion, because, well, recursion is messy and hard to follow if you are not the one who wrote the code. But with that said, you can just use AddHandler and RemoveHandler instead of the Handles clause. Remove the event handler for the mobility type dropdown before updating the weight, then AddHandler.

 

[Bad_Syntax]

Removing the handler's seem like a pretty good idea, at least for the controls that don't update other controls when they are updated. That would help in some situations.

However I'm thinking I just need more of a top down approach, something like a pyramid instead of a square, so once one change is made at a top level nothing that would invalidate that can be selected below it. I may just not be spending enough time designing these applications out before I start coding them.

Thanks, I appreciate the ideas and input!