Re: various objects in my VB6 project - Calling IUnknown

From: Mark G. Meyers (mmeyers[at]hydromilling.com)
Date: 06/30/04 

Date: Wed, 30 Jun 2004 19:34:33 -0400

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:OLOt%23stXEHA.648@TK2MSFTNGP10.phx.gbl...
:
> ... and there's at least one "groupie" around here that says "XPs not
> done until VB won't run".

Scary thought. To me, legacy support for EXEs is an order of scale beyond
language changes. Or is he referring to the IDE?

> Language Stability
> http://www.mvps.org/vb/index2.html?tips/stability.htm
>

Thanks for these links. "Language Stability" enjoyably employs structure.
But I'm not black and white on the matter of migration changes. Oh, APIs
for sure have to be careful - EXEs can die because of these things. But
look at it this way, I supported the ODBC API for a few years (a couple of
places), and watched as some things would get deprecated, and eventually
find their way out. That's not complete backward compatibility, but have
you considered that total backward compatibility may go too far? SQL'92 has
been tromped, albeit in more of an "every vendor now has their own SQL" kind
of way.

" Changes that break Language Stability:
.......
Changing ByRef to ByVal as default parameter behavior. Changes default
behavior established when procedures were introduced in early DOS versions
of the language. "

At some point, the position on the matter is source code migration, like
VB.NET's migration wizard, has to be exercised. A change like this could be
implemented in a migration wizard, and that would not be unorthodox to me.
Migrations are a fact of life, and when so easy to simplify, like with a
wizard, I think it can do more good than harm. On the other hand, the
matter of old things just dying without an upgrade path, or a very difficult
path, borders on the creation of....

> Visual Fred
> http://www.mvps.org/vb/index2.html?rants/vfred.htm
>

That is not insignificant! Golly, no MsgBox, but, MS says;

Null values and IsNull functions are commented with an upgrade warning.
For example, the following code:
 If x Is Null Then MsgBox "Null"
is upgraded to:
 ' UPGRADE_WARNING: Use of IsNull() detected
 If IsDBNull(x) Then MsgBox "Null"

Well, the name Fred sounds like a great idea.

Yes, it is flooring to read. VB6 can't be that much "end of life" (like
that individual you were talking about), or that would leave an awful lot of
people hanging.

> Developers expected to be able to load just about any code that can be
> considered "MS Basic" and run it largely unchanged.. which is why the
> End statement (and others like it) were preserved even though it's never
> recommended that you use End.
>

That presents to me the interesting note of VB developer expectations that
one may consider as varying in degree from other compilers or interpreters.
The most remarkable backward compatibility effort I have seen was on the
Mac, when moving from 680x0 chips to PowerPC chips.

> There should be an option to add Option Explicit to existing modules
> automatically but it doesn't look like it was a priority. I assume, this
> was mostly because VB programs were considered "throw away" by quite a
> few people in high places.
>

I don't quite understand this. If "throw away", then can't a simple change
like this be made without a fuss? I don't feel like old VB programs should
be regarded as "throw away".

> You'll find quite a few sample projects on the web that don't have
> Option Explicit. I ran into so many that, instead of adding it and
> fixing the missing declarations, I just toss the sample in the bit bucket.

I have to get me a bit bucket. Does that help?

> > the need. I've seen another make the mistake of modifying the caller's
> > primitive (default ByRef). It kind of freaked him out. Frankly, I
would
> > have guessed the basic types to default to ByVal, but I don't really
care
> > much about it. I just as a matter of habit don't modify the caller's
vars,
> > except with object refs, as they are coded to protect themselves. My
only
>
> When I started with VB, I got into the habit of creating a local copy of
> arguments myself.. even if ByVal is in place. A few wasted clock cycles
> vs knowing for sure I'm not messing up the callers variables. Knowing
> for sure wins <g> I still do it in most cases but not always.

Ah. The habit for me developed working with pointers and such passed in
(C++). Pointing to strange places, and causes wierd bugs. I guess I just
developed the mental habit of not altering args. (I'm very
maintenance/troubleshooting oriented at this point - it's the L3 support
conditioning). Folks who write miles of new code (that I have to support)
should have to fix a mile or two first!

> > Right! Unresolved problems within - that's the crux of it.
>
> About 95% of the time, I'll add a few Debug.Prints to each form or
> classes Initialize/Terminate event handlers and if they don't show when
> I expect them to, I go hunting for the cause. Most of the time it's not
> too hard to find.

> If there are circular refs (I use them very rarely), I'll add a
> "ReleaseRefs" (or similar) method that releases all circulars. After
> that, setting the object = Nothing should show a Debug.Print in the
> terminate event handler.

> fwiw, VB won't allow circular refs between projects in a group but
> doesn't check for circulars between compiled components... and VB6 is
> harder to shutdown cleanly than VB5 was (and VB5's harder than VB3). The
> newer the version, the more cleanup you need <g>

You know, as a profound matter of approach, I've been pretty stubborn about
this circular references thing. Like my liberties have been taken away.
But when you say, "VB won't allow circular refs between projects in a
group", that's a pretty strong case, (amongst other things said), for me to
drop it. And perhaps to come to realize I'm being a bit stubborn.

> Keep popping in for answers. Most of the regulars (there are quite a
> few) aren't hard to find.

I like it here! USENET and MVPs are MS developer's biggest boon.

Thx much -
Mark

Relevant Pages

  • Re: various objects in my VB6 project - Calling IUnknown
    ... > But I'm not black and white on the matter of migration changes. ... The upgrade wizard in VB.Net is a joke. ... you since you're not using the language of the day. ... We have way too much legacy code that we still need to support. ...
    (microsoft.public.vb.general.discussion)
  • Re: Lisp for numerical methods compared to other languages
    ... then it doesn't matter what language you use, or indeed, you're left ... There are toolkits which support this kind of environment, ...
    (comp.lang.lisp)
  • Re: Swing Migration from SBS 2003 to new SBS 2003 box
    ... If a typical migration used to ... You can swing from a plain old NT4 non-Exchange domain to a 2003 ... Microsoft offered nothing like this in the form of documentation, ... they did not want to support the process I had outlined, ...
    (microsoft.public.windows.server.sbs)
  • Re: Swing Migration from SBS 2003 to new SBS 2003 box
    ... If a typical migration used to ... You can swing from a plain old NT4 non-Exchange domain to a 2003 ... Microsoft offered nothing like this in the form of documentation, ... did not want to support the process I had outlined, ...
    (microsoft.public.windows.server.sbs)
  • Re: Celtic origin myths
    ... of a migration that never happened. ... Britain are from roughly that time, so someone was in Britain then.. ... the culture came later than the people, that the language and ... Europe to die off or be killed when IE peoples moved in. ...
    (soc.history.ancient)