Custom controls disappearing

  • Thread starter Thread starter Jared
  • Start date Start date
J

Jared

I've fought this problem on and off for quite a while now. My custom
..NET controls that exist in separate assemblies will *randomly*
disappear when I switch to the VS designer. VS doesn't always mark the
files as having been changed, so there's no way to undo. When this
happens, two important parts of the VS-generated code get wiped:

1) The code that adds the custom control to a container (hence the
disappearing act).
2) The code that links up event handlers. The handlers remains in
place, but they are no longer "hooked up" to the custom controls'
events.

I thought I had it licked by using file references instead of project
references. However, I just made a change to my control library,
rebuilt it, then opened a "consumer" project in the same instance of VS
(i.e. VS closed the control library project and opened the "consumer"
project). Voila, custom controls were gone, and I had no way of
recovering.

Because this is a somewhat complicated form with many instances of my
custom controls, it will take me a LONG time to redo my work. Worse,
this is very error prone, as it's easy to miss something. Worse YET is
that I have no guarantee it won't happen again.

-- start rant (feel free to ignore) --
IMHO, having your IDE eat your code and modify files on disk without
providing any means to recover is totally unacceptable. Also, "upgrade
to VS2005 for $$$" is not an acceptable solution, unless MS decides to
provide free upgrades.
-- end rant --

Does anyone have any tips for reliably avoiding this issue, short of
going back to Java programming in J-Builder? Please, please, don't
make me do that! :)

TIA

Jared
 
First, I find that whenever this happens to me, I can "undo" by closing
the Designer windows, then closing the solution and refusing to save
anything. Or, I just close the designer windows and shut down VS2003
and say "NO!" to all of its entreaties to "save my work." It has
always, thankfully, thus not saved its mangling of my form.

The problem seems to be that VS2003 recognizes that the assembly
containing the custom controls / base classes for forms / whatever has
changed, and thus its locally-copied version is no longer the most
recent, but hasn't the wits to either grab the most recent copy of the
relevant DLL or live with the stale copy it has. Instead it throws up
its proverbial hands and just nukes all related controls off the form.

Things get even worse when the DLL on which the forms depend
(containing the base class and/or user controls) didn't compile, so the
current project has a stale copy, and there is no newer copy because it
didn't build. The same sort of nonsense happens: VS2003 just decides to
drop all of the affected user controls from the form.

The secret, it seems, is to get the heck out without saving anything,
after closing all designer windows, as I said, and then restart VS2003
and, without opening any designer windows, rebuild the project. If you
can get a clean build of the project, VS2003 Designer seems happy and
doesn't do naughty things to your forms.

I usually start from the "bottom" (my library DLL) and work my way to
the "top" (the final app EXE, via my usercontrols DLL and my data layer
DLL), doing complete rebuilds at each stage and making sure that
they're clean. Only after everything builds successfully do I reopen
the Designer. I've never lost anything this way.

I don't do this every time. I do it only when the Designer decides to
be naughty.

And, as an aside, part of the problem is that you're doing development
with a fancy tool that writes source code for you, but you don't appear
to be using a source code control product. Very risky, even if VS2003
didn't have quirks. Get thee a free SCC package and start using it.
It's the only way to make sure that you can always recover.
 
Thanks for your detailed reply, Bruce. The behavior you described is
pretty close to what I'm seeing, with the rather significant exception
that VS removes the code from disk, not just its in-memory copy.
Hence, undo is not an option. In other words, there is no asterisk
next to the filename indicating it's been changed, the undo menu option
is disabled, and I don't get prompted to save when closing VS.

I use SourceSafe religiously, sometimes checking in code several times
a day. However, grabbing a version of a file that's even a couple
hours old can often mean losing valid changes, too. In fact, the
SourceSafe prompt to check out a file is often the red flag that VS is
trying to muck up my work. Unfortunately, this doesn't help when I've
already got the file checked out.

I think I'll get in the habit of closing VS completely and restarting
it when switching projects, as opposed to just opening a different
project in the same instance of VS.

Cheers!
 
Jared said:
Thanks for your detailed reply, Bruce. The behavior you described is
pretty close to what I'm seeing, with the rather significant exception
that VS removes the code from disk, not just its in-memory copy.
Hence, undo is not an option. In other words, there is no asterisk
next to the filename indicating it's been changed, the undo menu option
is disabled, and I don't get prompted to save when closing VS.

I use SourceSafe religiously, sometimes checking in code several times
a day. However, grabbing a version of a file that's even a couple
hours old can often mean losing valid changes, too. In fact, the
SourceSafe prompt to check out a file is often the red flag that VS is
trying to muck up my work. Unfortunately, this doesn't help when I've
already got the file checked out.

I think I'll get in the habit of closing VS completely and restarting
it when switching projects, as opposed to just opening a different
project in the same instance of VS.
Click to expand...

Not a bad idea... and one I've been using for VB5/6 projects forever. Quite
a few people know about VB and the way it "hijacks the registry" so it makes
sense to shut it down between projects and let it clean up after itself.

Coming from "the age before CPU fans", another habit to get into is.... save
and save often. Everytime you're thinking about code or a problem, whatever,
any form of "slack time" at all, hit the save button.... and, if
SourceSafe's giving you grief, don't use it from within the IDE, use it as a
standalone app. I do that fairly often... especially when I'm not exactly
sure what the result will be.
 
The behavior you described is pretty close to what I'm seeing, with the rather significant exception
that VS removes the code from disk, not just its in-memory copy. Hence, undo is not an option.
Click to expand...

I can safely say that I've never seen that behaviour. Yes, I've seen VS
not put the asterisk next to the name, but when I hit the big red X to
shut down VS, it always asks me, "Do you want to save your changes?" to
which I reply "Good Lord, NO!" and all is well again.

I get into trouble only when it mangles my form and I do a save, do a
build, or answer "yes" to the "do you want to save?" prompt.
 
Back
Top