"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:13*************@corp.supernews.com...
Johnny Jörgensen wrote:
>[...]
No matter what I do, I cannot update the old controls. I've tried
changing them in the designer file to regular ComboBoxes and back to my
derived combobox - Doesn't work.
I've tried removing the reference to the project in which the component
is located and readding it - Doesn't work. I've tried adding the new code
alongside the old code under a different classname and renaming the old
controls' class to the new controls' class in the designer file - Doesn't
work.
I'm lost now - have no more ideas! Why the h*** does it have to be that
hard?
How hard it is to fix a bug after the fact depends somewhat on in what way
you screwed up the code creating the bug in the first place.
You don't describe the bug, but if it's simply an implementation bug, then
as Morten say, recompiling the custom control's assembly should fix the
issue in any code that references it. Exceptions to this would be if you
have done something extra, like copying the custom control's assembly
somewhere else where you then referenced it in the using application, or
if the bug was related to some defaults for the control that then got
codified in an InitializeComponent() method somewhere.
Pete
Thanks for the vore of confidence Pete. First of all: The fact that new
instances of the control behaves correctly should be a good indicator that
the code is not screwed up. That is also why I don't describe the behaviour
in more detail - it seems irrelevant when I can see that the new control
instances behave correctly.
But if you'd like: The changes in the control are in the paint routines. As
mentioned, it's an inherited combobox. Before I took care of the entire
painting of the control in both enabled and disabled state. I got another
unexplainable bug in the control when the control was enabled: If you
CLICKED on the combobox to show the drop down list, everything was ok, and
the blue highlighting was only applied to the actual highlighted item. But
if you TABBED your way to the same control and pressed the down arrow, ALL
items in ALL of my inherited comboboxes on the entire form (not only the
focused one) became blue highlighted.
Seeing that the changes the customer wants are only with regards to the
disabled look, I thought: Why not just ownerdraw the control when it's
disabled and let windows handle the drawing when it's enabled. So in the
EnabledChanged routine, now, I simply switch to and from ownerdrawing.
That works perfectly in my test application and even in my real application
when a NEW instance of the new control is put on the form, but the "old"
instances behave in a strange way: Everything's ok when the control is
disabled, and when the control is enabled, it is painted correctly, but when
you drop the list, there is NO highlighting and NO item texts. There is a
scrollbar as if the items were there, but you can't see their texts.
The controls are all databound. I tried adding a new instance of the control
to the form and copy the databindings from one of the old instances. When
run, the new control shows the items correctly, but the old control doesn't
show any items att all (only the scrollbar).
I could fix the whole problem by exchanging all of the old instances with
new instances by dragging and dropping controls, renaming and setting
properties all over, but seeing that I have around 50 of the controltype on
one form only and that the control otherwise appears on other forms in the
project, It would be a tremendous task.
And anyway, all the old controls shold in my experience behave as the new
instances after building, but they don't!
/Johnny J.
