Enable Edit MenuItems based on Activecontrol

D

Denaes

Senior Contributor
Joined
Jun 10, 2003
Messages
956
Note: This is a repost of something I posted on the sister forums that hasn't gotten any replys.

What I'm looking for is a more simple way to Enable/Disable Edit Menu Items based on Active Control behavior.

Behavior (basically, I might miss something):
  • Copy/Cut/Delete - Only enabled when text is selected (SelectedText.Length is the way I normally go about it)
  • Paste - Only enabled if text is on the clipboard

I'm handling the event of the Edit Menu Dropdown and I can check the active control (Me.ActiveControl).

Now I hope I'm missing something, but it seems I would have to do a Select (or If...Then) to find out what Type the ActiveControl is and then write code Enable/Disable these MenuItems for each type of control.

I can do that, but I was hoping there was an easier way to handle this more generically that I'm missing. Any ideas?
 
You might find creating a class / component that implements the IExtenderProvider interface (Tutorial Here), this could then intercept the events of other controls on the form and toggle the menu items based on the type / contents of the control or clipboard.

Extenders can also expose properties that extend another control (e.g. the ToolTip control), this would allow you to also enable / disable this functionality an a control by control basis or even provide other customisations to the IDE.
 
Hmm, I'll have to look into that aspect.

I was digging around for a common interface, but no dice. The Textbox inherits from the TextboxBase which has these behaviors for the EditMenu, but the other controls that act like a TextBox have their own different Base, so Component is the only thing they have in common.

You'd think there would be an easier way to implement a windows standard, like it would be considered in the .Net development with the option of going your own way if you wanted to. Sort of like how the context popup works for the Textbox, exactly as you would expect with no fuss.

Thank you, I'll look into that tomorrow. I was also thinking that if we'd taken my advice from the design phase and immediately made a custom control extending each control, we could add interfaces and custom code as needed without having to gut forms replacing controls.
 
Problem with creating your own controls is you end up with a lot of duplication - TextBoxes, RichTextBoxes, ComboBoxes etc. all look like textboxes to the user but don't have a common base (not without going all the way back to Control) you can inherit from - you would need to provide similar functionality in each type of control. This gets worse if you are also using 3rd party controls as you would now have to inherit from these as well and provide your own functionality.

An extender is a pretty good way round this once you figure out how they work (this can take some doing ;)) as a single extender can affect multiple control types and isn't restricted to only the controls you can be bothered creating.
 
Back
Top