Re: Surprised to see UserControls Executing During Compilation!

Hi Joseph --

Very interesting.

Yeah, in a really esoteric way.

Ambient.UserMode is useful for a control which is directly hosted in
the form which is open in the IDE. Any nested controls though, will
see an Ambient.UserMode of False. Arguably this will be OK in many
situations. However, if you need to know absoluately whether you are
running inside the IDE (for example, you need to determine whether or
not to set up subclassing) then Ambient.UserMode is insufficient. We
use our own RunMode utility function (below) to make this
determination.

Also, Ambient.UserMode doesn't distinguish between Design Time and
Compile Time. Again, arguably, is this even necessary? In most cases,
no - according to my experience. A case where this might be necessary
is where the UserControl is hosted on a Form within the project in
which it is defined.

I guess I've just never noticed a case where this mattered before. Hard to
imagine something going weird if it fires during a compile?

What has me baffled is, with nested controls I see the ReadProperties
event firing for both the inner and outer controls when the host
application is compiled. What's that about? As far as I know, it's
the responsibility of the Outer control to bag all properties. I
guess though, that each nested control is responsible for its own
DEFAULT properties?

I suppose so, yeah. To follow your original assumption, the host form would
be responsible for the outer control's props?

Try that. It'll pop while the toolbar says "Writing EXE..." only
when the designer for the form isn't open.

I guess this is because, since the host form is not open, the
UserControl properties haven't been initialized and so this has to be
explicitly done at this point.

That makes sense.

If the form designer _is_ open, it
doesn't pop until the EXE has been fully committed to disk. I
honestly can't begin to offer an explanation for that pattern.

I guess we can speculate about why it doesn't pop while the compiler
is writing the executable. Since the host form is open, the
properties are presumed to be initialized and so it's not necessary.
The pop you describe, probably has more to do with refreshing the
form in the IDE after the compile is complete, rather than part of
the compilation itself.

WHich begs the question of why a refresh is needed. But, yeah, that could
easily be it.

(BTW, in a simple project with a single form,
I don't see this pop at all, following a compile.)

Were there any exposed properties in the test UC?

Thanks for your input. I now have a better understanding about why
code is executing during compilaton. However, nested controls aren't
as traightforward as simple controls. This whole issue bears further
investigation. If I put together a prototype or something, I'll
report back here. I guess I've been getting away with this for years
because the default behavior is sufficient for us. It would be nice
though, to know *exactly* what to expect under the complete variety
of possible scenarios.

I'm still pondering whether to care. <g> No offense, to be sure. Just,
again, never had a situation where this mattered, and have trouble
envisioning one still.

Thanks... Karl
--
Working without a .NET?
http://classicvb.org/


.