I have been thinking. When you want separate buttons for board and pieces, the board buttons must leave the pieces alone, and vice versa. Since the auto-generated buttons work by reparsing the entire Diagram definition (but accepting different lines as specified by the arguments of TwitchDiag()), the old setting for the set you don't want to change should be remembered.
This is how it already works for different armies: the white and black army settings are remembered in global variables wOld and bOld. And the buttons generated for changing the white army then call TwitchDiag(diagramNr, newWhiteChoice, bOld).
I guess the same method could be used for changing board and pieces. The 2nd and 3rd parameter of TwitchDiag() indicate the two sets of definition lines that should be included in addition to set 0. That piece lines in these sets get their white or black pieces suppressed is of no import when all the piece lines reside in set 0. So the 'white set' could be used for selecting board themes, the 'black set' for selecting piece themes.
The only issue is that when auto-generating a button for a set, the Diagram should know whether this is a button for the 'white' (= board) set, or for the 'black' (= pieces) set, so it can keep the parameter which it is not supposed to alter fixed. (In a different-armies context the perArmy=1 line would force both butoons to be made, in different rows.) Currently (without perArmy) it would always invoke TwitchDiag() with identical 2nd and 3rd argument.
I could make the perArmy parameter control that, e.g. by giving it the value 2 or 3. As long as it is 2, all buttons it generates would call TwitchDiag() with their own 2nd arguement, but with bOld as 3rd argument, and would then be board buttons. (That is, if you put board-defining definition lines in the sets selected by those buttons.) Buttons generated while perArmy equals 3 would pass a new 3rd argument, and use wSet as 2nd argument.
I have been thinking. When you want separate buttons for board and pieces, the board buttons must leave the pieces alone, and vice versa. Since the auto-generated buttons work by reparsing the entire Diagram definition (but accepting different lines as specified by the arguments of TwitchDiag()), the old setting for the set you don't want to change should be remembered.
This is how it already works for different armies: the white and black army settings are remembered in global variables wOld and bOld. And the buttons generated for changing the white army then call TwitchDiag(diagramNr, newWhiteChoice, bOld).
I guess the same method could be used for changing board and pieces. The 2nd and 3rd parameter of TwitchDiag() indicate the two sets of definition lines that should be included in addition to set 0. That piece lines in these sets get their white or black pieces suppressed is of no import when all the piece lines reside in set 0. So the 'white set' could be used for selecting board themes, the 'black set' for selecting piece themes.
The only issue is that when auto-generating a button for a set, the Diagram should know whether this is a button for the 'white' (= board) set, or for the 'black' (= pieces) set, so it can keep the parameter which it is not supposed to alter fixed. (In a different-armies context the perArmy=1 line would force both butoons to be made, in different rows.) Currently (without perArmy) it would always invoke TwitchDiag() with identical 2nd and 3rd argument.
I could make the perArmy parameter control that, e.g. by giving it the value 2 or 3. As long as it is 2, all buttons it generates would call TwitchDiag() with their own 2nd arguement, but with bOld as 3rd argument, and would then be board buttons. (That is, if you put board-defining definition lines in the sets selected by those buttons.) Buttons generated while perArmy equals 3 would pass a new 3rd argument, and use wSet as 2nd argument.
This sounds really simple...