To Refactor or not to Refactor

I created a WinForms combo box that restricts what options you can choose. This is for the situation where only a few of the options are valid choices at this point in your process, but the data you are binding to includes other values that must appear in the combo box to avoid binding errors. For example, it might be possible to manually change the status of any order only to Canceled or Hold, but the application allows the users to query and view orders of any status.

(ETA: we're assuming in-place editing, here. The problem goes away if you have separate read-only "Status" and write-only "New Status" controls. I'm not sure if you can do that with databinding alone.)

I created a stand-alone combo box version of this -- the RestrictedComboBox -- and also a DataGridView version. After a day or so of work it became obvious that rather than building column, cell, and editing control classes on top of the RestrictedComboBox, it made more sense to subclass the ComboBox versions of these classes.

This means that the RestrictedComboBox and DataGridViewRestrictedComboBoxEditingControl code files are made up of almost identical code. Both of them are descended from the ComboBox (directly in the case of the RestrictedComboBox, more distantly in the case of the other) and do their thing by interfering with combo box item selection and drawing. I'm toying with refactoring the common logic into a helper class. What do you think -- go to the trouble or not go to the trouble?