From: Karl E. Peterson on
Eduardo wrote:
> Karl E. Peterson escribi�:
>> Eduardo wrote:
>>> Karl E. Peterson escribi�:
>>>>> Another difference is that you have a reference to the form without
>>>>> having to set it to a property.
>>>> Sort of, yeah. You can't sink events from the parent without setting up a
>>>> circlejerk, right?
>>> I don't know what you mean here. It's quite easy to have the form's
>>> events with a couple of lines of code.
>> By passing a reference, right?
> You already have the reference, it's in the Parent property.

Hmmmm, ...

Y'know, I don't recall using *that* one together with WithEvents. Of course, you
can't sink any custom events using it, just the standard ones. (Because you have to
declare As Form instead of As Form1 since you'd never know the latter, more specific

That's kinda cool. It definitely alters my view of the utility of invisible
controls. This was my quick/dirty test:

Private WithEvents m_Parent As Form

Private Sub m_Parent_MouseMove(Button As Integer, Shift As Integer, X As Single,
Y As Single)
Debug.Print X, Y
End Sub

Private Sub UserControl_ReadProperties(PropBag As PropertyBag)
If Ambient.UserMode Then
Set m_Parent = UserControl.Parent
End If
End Sub

>>> But it is about *you*, that you are a programmer extremely experienced
>>> and exacting. VB is also for people that want to make programs easily.
>> Heh, do I sound totally like an Olde Fart if I say that sometimes the "easy path"
>> isn't? <g>
> No. I read about the idea the first time in the McKinney's book
> "Hardcore Visual Basic 5". I don't know who was the first to come with
> the idea, but it's not new to me.
> It's an opinion, but as I don't agree with it, now I'm taking the
> oportunity to discuss it with someone very qualified (you). So if I'm
> wrong, I want to see why.

Oh, you definitely woke me up! <g> Yeah, I can certainly see good reason to use
that to your advantage, if/when called for. Can't believe I was being so obtuse
there. I guess I always try to genericize everything, and to me "As Form" was a
barrier. It isn't, or doesn't have to be, especially for projects that just bundle
the UC right up inside.

> I remember that McKinney wrote that the Timer control shouldn't be a
> control, and that invisible controls shouldn't exists at all (or more or
> less that was the idea).

I agreed with that at the time. I wonder if he ever thought about this usage.
Anyway, for things like the timer, it's just kinda dumb. And not just because it's
inelegant, but also because of the window overhead. Although, it is easy.

> Besides the advantages I already mentioned (parent reference, design
> time property settings), I can mention another one:
> Going to the default event's code with just a double click.
> You double click in a Timer and you already are in place to write your
> code in the Timer event. That's nice.

Heh... I rarely look at a UI, but spend 99% of my time in the code windows.
Clicking there would absolutely take *me* a lot longer.

>>> Anyways there are controls, like the ImageList for instance, that you
>>> *need* to set up at design time if you want to avoid loading lot of
>>> files at runtime.
>> But that one's just accomodating other control/language shortcomings, eh?
> a) Do you mean that every control that will need a list of images should
> have built in capability to store the images?

No, but that it should be easier to load images at will. Resource files are nice,
and I use them when possible. But sometimes, you just have to draw things at
runtime. VB is just "awkward" for working with stuff like that. That all said, I'm
sure if I did TV/LV work all the time, I wouldn't have a second thought about it.
As it is, I use those controls twice a decade or so, and *always* have to go lookup
how to do the simplest things each time.

> b) ...or that the resource management should be much better and easier?
> I agree with this one.


> OK, I mentioned at least three things why I think that the invisible at
> runtime controls are justified (in my opinion), but what are the real
> drawbacks of having invisible controls?

There aren't any serious ones. I mean, you do get the added system overhead of
another window, which to the Ancient Byte Counters in the crowd is every bit to be
avoided as having an unused array element. Mostly it's an "elegance" argument, I
..NET: It's About Trust!

From: Karl E. Peterson on
Ralph wrote:
> Simply put: The advantages of an invisible ActiveX Control is that it is an
> ActiveX Control. The disadvantages of an invisible ActiveX Control is that
> it is an ActiveX Control.

That's a useful way of putting it. <g>
..NET: It's About Trust!

From: Karl E. Peterson on
Eduardo wrote:
> I don't get it... so you want to go back and have to write everything by
> code again?

Not necessarily again. (That's why so many of us were *so* pissed at MSFT with the
VFred fiasco, afterall! <g>) But yeah, we'd like to have *total* control over the
source code.
..NET: It's About Trust!

From: Karl E. Peterson on
Ralph wrote:
> Or to put it another way. An invisible ActiveX Control is nothing more than
> a 'regular' ActiveX Component, with container-awareness and a design-time
> presence.

and AsyncDownload!
..NET: It's About Trust!

From: Eduardo on
Tom Shelton escribi�:


I 've been accused of unfairly trying to read the minds of VB.NET
designers. Maybe so, although *I think you can interpret peoples
attitudes from what they produce*. People certainly interpreted my
personality from the text of my book, and many of them seemed to do so
accurately. But if I'm wrong about the VB.NET designers, if they really
are VB programmers who love Basic and have the spirit of the language
designers, Kemeny and Kurtz, then so much the worse. These results could
only be explained by incompetence and stupidity rather than ignorance
and arrogance.

Matthew 7:16 (Bible)
By their fruit you will recognize them. Do people pick grapes from
thornbushes, or figs from thistles?