Re: Surprised to see UserControls Executing During Compilation!



Hi Karl,

Were there any exposed properties in the test UC?

No, that might be a good point to investigate.

I'm still pondering whether to care. <g>

Yeah, me too ;-). It'd be on my own time...

On the main, this evidently works well since among all of us, only one of us
(me) has *ever* seen a compile time issue where this made a difference. Even
that wasn't in our own code - we purchased a third party control with source
code and then proceeded to to something else non standard with it; that is
wrap it inside a hosting user control and then host the outer control on a
form, all of which exist in the same user control project (whew!) and then
proceed to compile. Interestingly enough we did note at the time that when
compiling interactively, with the host form open in the IDE - no problem.
However when compiling in batch (our automated compiles are performed in
batch) the compile would fail.

Actually, I do care. I'm just pondering whether I care enough to do anything
about it ;-)

- Joe Geretz -

"Karl E. Peterson" <karl@xxxxxxxx> wrote in message
news:%2384%23pMyjGHA.1264@xxxxxxxxxxxxxxxxxxxxxxx
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/




.



Relevant Pages

  • Re: Difficulties programming a command button
    ... Twice when I tried to compile Access hung and I just ... and selecting 'Yes' opens the Excel file. ... I doubled checked the sheet names to what I had in the ... The name for the control for the equipment is “txtEquipment”. ...
    (microsoft.public.access.modulesdaovba)
  • Re: User Controls are dissapearing at designTime
    ... go into configuration manager and set all control projects to compile ... The user control is embedded in the project (a ... > reference in the project is not pointing anymore to binary. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: Access Violation Exception
    ... In VB6, in the project's properties, go to the Compile tab and select ... This will create a PDB file when you compile ... where the error occurred in the custom control. ... > I have a vb6 app with various custom controls. ...
    (microsoft.public.vb.winapi)
  • Re: Access Violation Exception
    ... This will create a PDB file when you compile ... > where the error occurred in the custom control. ... >> I have a vb6 app with various custom controls. ... App enters into a loop where it displays the exception error and it ...
    (microsoft.public.vb.winapi)
  • Re: EXE hangs!
    ... I have been logging to a textbox on my application. ... to a property of an ActiveX control. ... I was checking the state of the DNS microphone control at a somewhat ... compiles into, so that I can write things that compile efficiently. ...
    (microsoft.public.vb.enterprise)