Improved the Add and R Help buttons with scrollbar on the General Graphic Dialog

[N-thony]

@rdstern I have the change for the Add and R Help in the General Graph since both have long list and not display nicely for users.

now they are using a scrollbar, have a look

[rdstern]

@N-thony very nice. I am also happy with the size, but just wondered if a bit longer may be even better?
But then they stopped working, which makes me wonder about the code? I used it twice for the geoms and was pleased it also remembered its place in the list. Then I went to the R-help and that worked fine. Then back to the geom and then the second time, the help drop-down didn't work.
From then on neither down arrow works. Nothing happens. I tried reset, different data frame, closing the dialog. I have to start R-Instat again for them to now work again.

[rdstern]

@N-thony in the geoms the order is odd and some are repeated. They are ok and alphabetical in the long version:

I can't though get it to stop working so that seems well fixed.

[rdstern]

@N-thony that's very nice now. @Patowhiz good for you to check and merge.

[Patowhiz]

@rdstern is it functionally correct to allow multiple additions of the same geom? Or should we enforce a single addition?

[Patowhiz]

@N-thony why did you choose to add a list box to the split button instead of just making the split button context menu scrollable?

[rdstern]

@Patowhiz yes you can have the same geom multiple times. This could be for the same layer, but the more common examples are when you plot, say tmax and tmin against date. You start with tmax against date, say with geom_line and then again for tmin.
I like your query for @N-thony. If I understand correctly, you feel we could be re-using an existing custom control, (changing the properties), rather than adding a new one? This is becoming an important, and one of our nicest dialogs - in my view anyway - so I look forward to merging the improved version.

[Patowhiz]

@rdstern thanks for your feedback.
@N-thony try looking into whether the context menu can be made scrollable and it's size fixed. If that's possible, then we won't need a list box, which means no additional controls and public functions will be needed.

[N-thony]

@rdstern thanks for your feedback. @N-thony try looking into whether the context menu can be made scrollable and it's size fixed. If that's possible, then we won't need a list box, which means no additional controls and public functions will be needed.

@Patowhiz I have done the investigation on this and did not find a possible way to make a context menu scrollable. You can have a look of different forms like here and here and you will see this one of the alternative as there is no way to make it scrollable

[rdstern]

So @Patowhiz can this now be accepted and merged? I am keen to proceed well, but also quickly - so not striving for perfection if what is here is ok.

[Patowhiz]

@rdstern and @N-thony thanks for your feedbacks.

@rdstern, the focus here isn't on achieving perfection but rather on minimizing the set of alternative functions within the control. Introducing two ways of accomplishing the same task, when one suffices, adds unnecessary complexity and hinders future developer agility. While having multiple approaches can be justified in certain scenarios, in this case, it seems unwarranted.

Note, this feature is currently needed in one place, in future we will most likely use it differently places, leading to different ways of using the same control. One way that uses the context menu, another way that uses a list box. One way that allows a developer to use the visual studio designer, another way that requires the developer to use the controller code file.

Introducing unnecessary diversity in approaches often leads to bugs, as maintaining multiple ways of achieving the same outcome becomes a challenge. Therefore, my recommendation is to default to extending an existing method, promoting consistency and minimizing potential issues down the line.

@N-thony trying adding the context menu inside a panel then make the panel scrollable. Then you can modify the existing code that shows and hides the context menu to show and hide the panel. This will ensure no external changes are needed by dialogs that use this control. They will always just use the context menu. If you find this difficult to do just let me know, considering @rdstern urgency to have this merged, I will merge this and later do the PR using the approach.

Below is a sample code how I would have put the context menu inside a scrollable line. Then the panel could be shown or hidden in a similar way you have done with the list box.

// Enable vertical scrollbar for the panel
panel1.AutoScroll = true;

// Place the ContextMenuStrip inside the Panel
contextMenuStrip1.RenderMode = ToolStripRenderMode.System; //You can ignore this line if it's of no use
panel1.Controls.Add(contextMenuStrip1);