Behaviour:
With user initially selecting tglb_hp_flds, sub togglebuttons1 is executed. tglb_hp_flds is depressed (value=true), all other buttons set to value=false to reset any previously selected buttons. Listbox properly populates as per code.
However, when the user then selects tglb_hp_dias, togglebuttons1 executes, but triggers the tgbl_hp_flds click event when tgbl_hp_flds value is set to false (to reset it from the previous selection).

Application.EnableEvents cannot be used as its a userform. I tried the suggested alternative to use a booleen variable (mbEvents) to suppress unwanted userform events from triggering during initialization for example. I need to use it (or something) here to prevent triggering of click events during resetting.

It is obvious that I have either coded wrong, or have taken the wrong approach as it appears my efforts are failing.

There is a chance I may not have interpreted your suggestions accurately as this appears to not have made any improvement.

I have changed my toggle button click events ...

Code:

Private Sub tglb_hp_dias_Click()
If mbEvents Then
toggleclicks1
End If
End Sub
Private Sub tglb_hp_flds_Click()
If mbEvents Then
toggleclicks1
End If
End Sub

I then reviewed at the togglebuttos1 code trying different options from removing all references to mbEvents (for which I removed me. in all), to leaving in the the mbEvents=true and mbEvents False in each "if" routine. In addition to your suggestion for the togglebutton click code, I was unsure what, if any changes needed to be applied to the togglebuttons1 code.

You should not reference mbEvents in the toggleClicks code with the exception of turning it ON or OFF at the very end of the processing. Actually this could be done in each Click() event when execution returns from toggleClicks.

I know that you are trying to write efficient code by using a standard click handler, however this can lead to problems if you are not sure exactly what you are doing. You may be better served by writing each click event code separately (without outside calls) until you get your code working the way you want. Once you have that solved you can then look at the code for commonality and ways to move some of the redundant code to a common function.

Again, it is hard to give concrete advice when we can't see the whole problem. This is why posting a sanitized copy of your workbook will result in much better and more targeted advice.

Next get rid of the ElseIf chain. These are extremely hard to follow and the If ... Exit Sub statements violate good coding practice of one entry/exit for each function. If you haven't I'd suggest you create a good old fashioned flow chart for the logic you need to accomplish this task as that will likely make things much clearer and easier to code.

Also you should adopt a standard indention sequence like that shown in the code above again to make the code easier to read and follow.

Thanks RG for the constructive criticism. I appreciate the comments and understand the importance of proper structure. Much of what I had posted was a result of throwing code in for trial and error based on internet search suggestions (not best practice but without formal training that is how I learn best), so much of the structure was lost and likely some unintended redundancy. There is no doubt that my entire project could find efficiency through improved logic I will clean things up to see if that will help me follow the logic a bit better.

It has been suggested to use option buttons to do much of what I am struggling to do. Certainly something to consider if all else fails, but the buttons look a bit out of place on my userform. When I approached toggle buttons as a choice, I didn't realize that coding a value change was the equivalent to a "click". Now I realize that a click is simply a means of changing the value between true and false. I guess I'm just committed to seeing this through at this point. Optimistically speaking (and again without learned knowledge), I think finding the proper placement of the mbEvent codes may be what is needed.

It looks like my hurdle has been overcome.
After cleaning up my code (replaced at least one if / then / end if structure with case), it was suggested I "reset" the toggle buttons in the togglebutton click code and remove such, and any mbEvent handling code from the called upon routine:

Although not a traditional use of Select Case (usually it is used to test differing values of the same variable) you can use it to make your code easier to read. I made a test program from your code that does not depend on the form but it will demonstrate the use of the Select Case construct in this instance.

I ran the code once for each possibility (starting with the first one true then moving down each time having only one true until the last run which had all falses) and here is what is printed out by the Debug.Print statement in the immediate window.

Code:

=D* 0
=F* 0
=C* 0
1
<> 0

Note: If more than one of the values were True only the first one encountered in the Select Case would be executed!

Of course when adapting this for your code you'll need to add the .Value back in and replace the statements I removed. Basically, you just want to copy the logic, e.g. replacing the ElseIf with Case etc.

You'll also notice that the Case statements merely use the variable name, as the variables are boolean (True/False) that's all you need there is no need to test against a value with an equal sign.

Finally, Like If statements Select Case statements can be NESTED just make sure you keep you're End Select statements matched up.