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

Re: Usercontrol changes doesn't compile?

On Tue, 07 Aug 2007 18:00:48 +0200, Johnny Jörgensen <jojo@altcom.se wrote:

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.

--
Happy coding!
Morten Wennevik [C# MVP]

[Peter Duniho]

Re: Usercontrol changes doesn't compile?

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 InitializeCompo nent() method somewhere.

Pete

[Johnny Jörgensen]

Re: Usercontrol changes doesn't compile?


"Morten Wennevik [C# MVP]" <MortenWennevik @hotmail.comwro te in message
news:op.two6rjd rdj93y5@stone.. .

On Tue, 07 Aug 2007 18:00:48 +0200, Johnny Jörgensen <jojo@altcom.se >
wrote:
>

>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.
>
--
Happy coding!
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.

[Johnny Jörgensen]

Re: Usercontrol changes doesn't compile?


"Peter Duniho" <NpOeStPeAdM@Nn OwSlPiAnMk.comw rote in message
news:13bhccdo68 7otcf@corp.supe rnews.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 InitializeCompo nent() 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]

Re: Usercontrol changes doesn't compile?

Johnny Jörgensen wrote:

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]

Re: Usercontrol changes doesn't compile?

Johnny Jörgensen wrote:

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

>
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