Usercontrol changes doesn't compile?

[Johnny Jörgensen]

I've got a usercontrol derived from a normal ComboBox that contains some
special formatting code. On my main form I've got a lot of my custom
comboboxes.

I discovered a bug in the derived control and fixed it. But it still doesn't
work for the controls already added to the form. It works fine for new
instances of the control dragged from the toolbox to the form.

I don't want to have to drag and drop new controls to exchange all my old
controls - that is a sure way to introduce errors...

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?

/Johnny J.

 

[Morten Wennevik [C# MVP]]

I've got a usercontrol derived from a normal ComboBox that contains some
special formatting code. On my main form I've got a lot of my custom
comboboxes.

I discovered a bug in the derived control and fixed it. But it still doesn't
work for the controls already added to the form. It works fine for new
instances of the control dragged from the toolbox to the form.

I don't want to have to drag and drop new controls to exchange all my old
controls - that is a sure way to introduce errors...

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?

/Johnny J.

Hi Johnny,

How are the Form and the UserControl related? Are they in the same project? If so, usually a recompile should be sufficient, though you may need to close and reopen the designer view to have it update itself. If you are referensing an external assembly make sure the referense is updated. Check if the new assembly is copied locally if needed, and maybe delete and recreate the referense.

 

[Peter Duniho]

[...]
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

 

[Johnny Jörgensen]

Hi Johnny,

How are the Form and the UserControl related? Are they in the same
project? If so, usually a recompile should be sufficient, though you may
need to close and reopen the designer view to have it update itself. If
you are referensing an external assembly make sure the referense is
updated. Check if the new assembly is copied locally if needed, and maybe
delete and recreate the referense.

The form is in one project and the control in another, but in the same
solution. The control project is of course referenced in the form project.

Recompiling doesn't help - nor does it help removing the reference and
adding it again.

The fact that a new instance of the control added to the form behaves
perfectly seems to me to indicate that the build and reference for the
control is ok. But it doesn't explain why "old" instances of the control are
not updated. I can have the same type of controls on the same form that
behave in two different ways.

It's VERY strange, and I've never had any problems with custom and user
controls not updating before.

Cheers,
Johnny J.

 

[Johnny Jörgensen]

[...]
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.

 

[Peter Duniho]

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.

You misunderstand. By "screwed up" I am referring to the bug you fixed
in the first place. IMHO, the word "bug" necessarily implies that "the
code is screwed up". If the code wasn't screwed up, there wouldn't be a
bug.

I still don't know why your control isn't being updated, but I strongly
suspect that you've got an extra copy of the previous assembly sitting
around somewhere that's being used, with the reference to the new
assembly only being used when you drag a new instance of the control
onto your form.

So the first thing I'd do is do a disk search for that assembly, and see
if I can find any other copies somewhere.

This is a little over my head, but I gather that .NET actually caches
some assemblies so one thing you might want to look into is whether that
cache is somehow involved.

Pete

 

[Peter Duniho]

But then surely I should have two references visible in my project?

That seems like a reasonable assumption, but since it seems like a
reasonable assumption that fixing the bug in the original component
would propagate to existing instances of the component in existing code,
and since that reasonable assumption is obviously false, you need to
forget about reasonable assumptions and start from scratch.

You've got a situation that should not be happening. At least in my
experience, VS and .NET are reasonably bug-free, and at the very least
for you to run into something like this, something has happened that is
more complicated than you have a reference to a component, changing the
component, and the behavior of that component not changing in the
already-referenced instances.

The "instance" of the component in your existing code is just code using
the public API of your component to instantiate the component at
run-time. It's not like the implementation of that component is somehow
incorporated into the referencing code. So, either there's something
about the public API used in the instantiation you haven't mentioned, or
there's something you've done that's different from the usual mechanism
of referencing that has led to the previously-compiled assembly still
being around and still being used.

Which of those situations is the case, I don't know. You seem to be
implying that the former is not a possibility, which leaves us with the
latter. Since I have never run into this particular problem, in spite
of having several .NET projects that refer to other .NET projects, and
in spite of being able to make changes to the referenced projects and
having those changes appear in the referring projects, I can't offer
specific advice about what might wrong.

But I can confirm that normally this just works fine. The logical
conclusion is that you've done something that's not normal. Perhaps not
on purpose, and perhaps not even with you realizing it. But regardless,
to fix it you'll either have to go with the work-around you know works
(replacing existing instances with new instances), or you need to
abandon any reasonable assumptions you have about how this _should_ work
and consider all the possibilities of how it _is_ working, even when
that seems like it involves unreasonable assumptions.

Pete

 

[Morten Wennevik [C# MVP]]

The form is in one project and the control in another, but in the same
solution. The control project is of course referenced in the form project.

Recompiling doesn't help - nor does it help removing the reference and
adding it again.

The fact that a new instance of the control added to the form behaves
perfectly seems to me to indicate that the build and reference for the
control is ok. But it doesn't explain why "old" instances of the control are
not updated. I can have the same type of controls on the same form that
behave in two different ways.

It's VERY strange, and I've never had any problems with custom and user
controls not updating before.

Cheers,
Johnny J.

Strange indeed. I've had some problems of usercontrols not updating properly, but those have always been tracked down to Visual Studio not updating the reference properly, and solved by a recompile or several or restart of Visual Studio or in the worst case, a reboot. With several projects in a single solution, build order comes into play where some projects aren't built when you do a solution build, but since new controls work fine I doubt this is the case here. It seems more like there are multiple versions of your usercontrol, somehow.

It would be interesting to see if you remove the usercontrol reference, do the old usercontrols still work? Could they be referenced via another reference?