Those people in this group bagging .net are those who don't really know it.
Anyone who's bothered to learn it seems to understand why it's superior.
Sorry guys, I just had to say it after reading through a thread about why
vb6 is better than dot net because someone couldn't work out how to change
the startup form on their first day of using it and other similarly minor
issues. :-)

Michael

Michael C wrote:
Wouldn't it be nice if there was a ng where people who still use VB6
could discuss VB6 problems and not anything else!

Mike

That way they could keep their head in the sand completely. :-)

Michael

were released on Thu, 6 Oct 2005 15:35:31 +1000 bearing the
following fruit:

Like it or not, this group is here to support people working
with VB6 and earlier.

VB6 code will be around for many year to come and if you
don't think so then I've got about a million lines of vb
code for you to convert ;-(

Some people choose to stick with VB others have no choice,
either way this group is here to support them.



Jan Hyde (VB MVP)

On Thu, 6 Oct 2005 15:35:31 +1000, "Michael C"
<mculley@NOSPAMoptushome.com.au> wrote:

Ok, so let's start discussing Delphi here

Heck, lets be really promiscuous and discuss Linux

We could even discuss politics

- all in the interest of keeping our heads out of the sand

There's a lot of good stuff in the sand. There's something
for all of us... For instance, in the order of protein, you end
up with cockroaches, beetles, and various types insects. If
your vegetarian, quite a bit can be grown from the sand,
including pineapples, carrots, onions, corn, lettuce, basil,
cucumbers, coconuts, mangos, avocados, oranges, chives,
tomatoes, peas, lima beans, green beans, grapefruits, and
some of the best peppers around, including serrano, jalapeno,
hungarian wax, and a variety of multicolored belle peppers.
If you maintain a nice compost pile for additional nutrients,
you end up with a really fabulous collection of fruits and
vegetables. The list definitely doesn't end there. For added
protein skim the surface of the sand, look for snakes,
centipedes, frogs, a wide variety of insects and arachnids.

There's more to sand than Michael C knows about. The
problem isn't the sand is bad, and his analogy represents
a poor characterization. There's a ton of great stuff in the
sand. There's a ton of great stuff that comes out of the
sand.

As my friend Obi Wan Kenobi said, "Don't fall to the dark
side, Michael C. Keep the light in your eyes and see some
truths."

wow, a wise man. You live on top of some mountain far far far away?






Show quoteHide quote

They are not keeping their heads in the sand, it's about the time and effort
to learn everything you need to know about the language and platform before
proceeding. Knowing the differences between the 2 languages is not enough,
since the controls and libraries of the 2 languages behave differently.
Those who know everything about the target language and platform and design
the software completely in flow charts and other forms before writing a
single line of code produce the most flawless systems with the fewest
possible bugs, IMO. When designed that way, design bugs can be discovered
early on in the design stage.

When someone goes on and writes the code and fixes problems as he or she
goes along, it would be time consuming to find and fix design problems. The
process usually goes like this:

1 - Write your code.
2 - A Bug was found.
3 - Fix it and test the code for 10 minutes.
4 - It tested OK, so do a full functionality test that takes 1 hour or more.
5 - Opps, not really fixed, go back to step 3 and repeat till it's fixed.

The problem with this approach is step 4, that's why large projects take so
long, a full functionality test might take longer than 1 hour, perhaps a day
or more, perhaps it means a release to a beta tester or a customer which
takes few days. So multiply this by n problems and the software would take a
loooong time to finish. It's why a boss or a team leader hears "I finished
90 or 95%" and they seem to run out of percentage points every time they
have to make a progress report, the thing seems to take forever, stuck in
trying to solve a bug or a "minor" redesign.

I once spent about 3 weeks designing a software from head to toe with
detailed flow chart, almost one flow box for every line of code,
anticipating every problem and changing the design if necessary. I used an
Excel sheet it to list my global variables and a description of what they
do. After the design was approved, it took few hours to write the 1000+
lines of code and was wrapped up completely within 2 days. I only found one
design bug that I have missed, which was fixed in about 2 days. That
software was using assembly, not VB6. It performed a lot of background
operations at interrupt time and hence the difficulty in writing it.

So unless someone knows "everything" to know about the target platform,
language, and the libraries required to finish a project, one cannot be sure
of the outcome and how long it takes to finish a project. One might learn
the new language and do simple programs from time to time so not to be left
out of the loop, but when it comes to large projects, you are better of
using what you already know to save your time. One could though make the
code more compatible with the new version, by explicitly using "Dim" for
each variable, and using "ByVal" and "ByRef" explicitly for instance.

You probably still using Declare statements in Vb.Net, MS does not prefer
that dotnet developers resort to the API. They have to stick with the dotnet
run time. The reason for this is multiplatform compatibility. MS could in
the future come up with a hypothetical VB2010 for Windows, Mac, Linux, and
Unix. If you use the API directly, it has to go through a translation layer
and would be slower than using the dotnet runtimes. MS has already made a
full translation layer for Macs, see Virtual PC for Mac, which allows you to
run Windows Apps on a Mac. I don't think they have made a dotnet library for
Mac yet.

http://www.microsoft.com/mac/products/virtualpc/virtualpc.aspx?pid=virtualpc

MS also made IE and Office for Macs:

http://www.microsoft.com/mac/

As for Linux, See also this dotnet library for Linux:

http://www.mono-project.com/Main_Page

I am not sure if it's complete or how far they have gone with the project.

superior is relative. Some are interested in minimum dependency as much as
possible like myself, so a network administrator can install my app on
hundreds of computers via a login script without rebooting most computers(if
I included the oldest possible version of DLL's/OCX's that my app require to
function correctly). My upgrade path in some of my programs seems to be from
VB6 to C++.Net 2003, which is the only .Net language that can compile to a
classic EXE file without dependency on .Net. The compiled code also works on
Windows 95 as others have tested even though it's not officially supported
by MS. Some of my customers are still using Windows 95, so VB.Net is a
no-no.



Show quoteHide quote

Michael C wrote:

I wonder what the .net ng's call people like you who go there and
repeatedly post irrelevant noise.

use VB6 could
My guess would be... Michael C. <g>

Rick

It doesn't seem to me like a good advertisement
for .Net that new .Netters keep hanging around, shrieking
to "everyone and his brother" that they're using the
wrong language. You profess to be very confident in
your fashion choice. Yet you're hanging around here -
in this apparently seedy joint for has-been languages -
trying to convince yourself that you made the right
choice; while you could be out strutting your shiny,
new O.O. stuff.   :)

Show quoteHide quote

in <OXg8k0iyFHA.2***@tk2msftngp13.phx.gbl>

I for one will very definitely NEVER look at any of their software development
tools EVER again regardless of any supposed superiority because I refuse to be
put in the situation AGAIN of refactoring my bread and butter app at the whim of
some completely out of touch wienies in Redmond.

No, I don't know it and I don't CARE to know it.  And I don't CARE whether or
not it's superior.  All I care about is that they've trashed my assets on a whim
and left me with no forward migration path other than a complete rewrite. 

Eventually that attitude will come back to bite them no matter how big they are.

I like to imagine the uptake on .NET as being much like the saying "Suppose they
called a war and nobody came?"

---
Stefan Berglund

Michael C wrote:
So, you _have_ signed the petition, then?

Troll, troll, troll your boat.

That's the second tttyb i've got :-)

Michael

That "someone" would be me <g>. Here is the "offending" paragraph:

"How about adding the fact that if you change the start up form's name,
the project will no longer compile because you have to change it
manually
somewhere. I did this a while, then left it alone and came back a few
months later and I could not remember where I had to set it!! I ended up
renaming my form back to Form1. Just beautiful."

This was in response to another post that listed stuff about .NET that
the
poster did not like, but I never mentioned that any one technology or
language was "superior" to another. I know far too well that the
superior technology is the one that gets the job done in the best way
for the client.

Just to clarify, I started using .NET 2002, but then I started working
for a firm that has a substantial code investment in VB6, so I left .NET
alone for a couple of years. Then while tinkering a few months back I
built a quickie .NET sample app, changed the start up form's name
and this is when it did not compile. I knew what the error was and knew
how to fix it, but much to my dismay I could not remember where I
had to specify the startup form's name. So the quick fix was just to
rename the form to its original default name. I was not a in position
to actually look for this info, so the quickest and most practical
solution
was to name the form back to tits default name.

I certainly would not classify a language as inferior based on this
experience, but I did find it annoying that I needed to manually
change this when it is done "automatically" in VB6, regardless of
what goes on behind the scenes to justify the need for the manual
work needed (not to mention my lapse in memory at that time).
Obviously, this procedure might be different depending on what
language/technology you use to develop.

Have great one Michael!
Saga


Show quoteHide quote

And in defense of .NET, VS 2005 has finally solved this problem.

Some of the greatest gains in .net have been from removing the automatic
features of vb6.  Having code specify the startup form is much clearer and
self documenting. VB6 had 2 methods of achieving this which really is more
to learn (only slightly I know). It's the same with putting controls on
forms, it's all done in code now so you can see what's happening.

Michael

Heres what I noticed...

Is it just me or is anyone else curiously watching Google ???

I'm placing bets that they are writing a new OS which will in all
likely-hood blow doors compared to MS if for any reason, that they do
everything else so well (IMHO)...  They have hired every great mind they
can get their hands on and now have a contract with Sun...

Anyone on the fringes of their organization? Got any clues? Heard any
neat stories?

D?

Show quote Hide quote Well. Some of their new stuff may be technically sharp, but hasn't been that
big of an improvement. (IMHO). I think any company in that league dreams of
becoming the desktop/platform king of something. But it will take more than
just something technically superior. The pathways where M$ has tread is
littered with the bones of technically superior products.

[Based on history, being an ally of Sun is no great plus. <g>]

Years ago, I was mildly concerned when Borland was basically kicking butt
with their development tools and M$ was apparently dragging theirs. But knew
there was no real danger since M$ 'owned' the platform. Then of course
Borland commited suicide.

However, based on my own recent experience listening into meeting-room
conversations - M$ is ripe for the taking more now than ever before. They
have become unknowable, expensive (TCO is higher than ever before,
Development cost are becoming prohibitive for small organizations), their
nearest competitor is free, and they have just alienated a large segment of
their base. And all the big boys out there know it. I look for someone to
make a serious run this Spring.

Ballmer doesn't strike me as the man who can defend. Too slow, too
short-sighted, too embedded with a M$ view of the world (why not, he helped
to create it). I don't think he will even see it coming.

-ralph

in <drednVnz3dYnb9jeRVn***@arkansas.net>

Show quoteHide quoteYes, yes, yessssssssssssssssssss please!

---
Stefan Berglund

Lot's of replies but everyone seemed to avoid the issue raised, which was
those who most against .net seem to be those with the least knowledge of it.

Michael

Don't conflate .net with VB.Net; the two are not the same.

Most of what you seem to be taking as petty arguments against VB.Net I see
as proof of the biggest problem with it.  MS pulled the rug out from under a
very large developer base by creating an "upgrade" that is incompatible at
every level from major design approaches down to minor keyword and IDE
changes.

The primary issue with VB.Net is and always has been *trust*.  Whether it is
superior or inferior or just different is irrelevent.  It's quite obvious
that MS does not have any respect for the language or the developer base
that has long made extensive use of it and I for one will not commit to a
language that the provider doesn't commit to.

As the sig says... Fool me once, shame on you; fool me twice, shame on me.
With the data type changes in the unimess fiasco MS managed to fool me once.
With VB.Net I'm looking harder behind the curtain and seeing nothing but
smoke and mirrors.  If you think it's worth something then by all means use
it and good luck -- you'll need it when VB.Next comes along.  In the
meantime, please stop trolling here.  This group is one of the few places
left where people can get support on VB applications and as such needs to be
preserved.  There are plenty of forums available for those gullible enough
to use VB.Net to discuss that.

I was just pointing out the ignorance of a particular statement, I didn't
make the statement.

Michael

Michael,

You obviously don't understand what the problem is, or just haven't
listened. I've been working on an ASP.NET project (VB) for about three years
now, and would guess that I've got close to 30,000 lines of code. The
project contains several DLLs, several web server controls, a web service,
etc., besides healthy doses of JScript, HTML, XML, and you name it. But on
the other hand, our company has about half a million lines of VB6 code on
which four different developers work. There is NO WAY we can cover the ROI
to get those lines into .NET. We have studied all the possiblities and they
would all take us right to bankrupcy. Knowledge has nothing to do with it.
ROI has everything to do with it.

Gary

I was never disputing that, ALL I was saying is that those who say it is a
poor language know SFA about it. You obviously know a lot about it and I
noticed you didn't say it was a poor language. :-)

Michael

Michael,

Actually I doubt that many here would actually affirm that Vb.Net is a "poor
language". It's more a case of 'sour grapes'. VB.Net is simply out of reach
for a lot of classic developers (including myself). But it's out of reach,
not because we are incapable of learning it or that we don't like it, but
rather becasue we have too much code to maintain and too many clients to
keep happy. There is a very high probability that we will still be
developing VB6 programs five to ten years from now, not because we want to,
but because that is the only way we can make a living.

If there was a magic button which would convert our code (or at least a
decent amount of it) to VB.Net this discussion wouldn't exist. I wonder if
MS has taken note that five years after the presentation of VB.Net these
discussions are still taking place (I doubt it). In my opinion, the decision
not to make VB forward compatible was a serious design flaw, and if it was
my company, there would be some heads rolling. If MS had given us a way to
get our code into .Net, I'm sure that .Net would now be the dominant
platform in software development. Instead of that, one of the main
competitors to the .Net platform is curiously VB6. MS has to compete with
it's own product, and to make it worse, it no longer makes any money off of
VB6.

Gary




Show quoteHide quote

Show quote Hide quote In MS's defense (kind of) I can appreciate why MS made the decision they
did.

Ignoring for a moment the obvious benefits of abandoning COM (Dll Hell and
the security risks) and the advantage of exposing the entire OS and its
services as one large class library. The major motivation for .NET is the
savings of millions of dollars in maintaining diverse development groups. It
is often overlooked that .Net is a major dollar saver for MS.

This decision is little different that what many a board-room goes through
when they decide to go with a single platform and language for all their
development.

To provide an adequate 'migration' path for VBc applications would have been
expensive. There is far more involved than merely maintaining some
'language' compatibility. It could have been done, but it wouldn't have been
cheap, and it wouldn't have been flawless. (Witness some of the early horror
stories with C++ manage code.) Even if they had decided to create such an
animal, I doubt a 100% 'stable' VBc-VB.net conversion addin/designer would
even exist until now (dotnet 2005).

Plus in the meantime they would not only have received the same criticism
concerning dotNet, they would have had to listen to why their conversion
process was so clumsy.(However, had they created a license agreement for the
VBRuntime, VB IDE, and binary formats - I think they would have been amazed
about how much 3rd party, mvp, et al support they would have gotten. But
that is another story.)

So here is this 'decision-maker' (call him 'Mr. B') making his plea to save
millions of dollars. Look how much better the ROI looks if Mr. B says - by
disbanding the VB/COM group we save X million dollars now, and continue to
save X million over the next 5 years - compared to saying - if we spend this
X millions now we will preserve the investments of others and make other
people happy. As far as Mr B is concerned, it is a no-brainer.

If you consider a dollar saved is worth fives dollars spent to make three,
then add in the sheer bad manners that comes from being #1. (To paraphase an
earlier 20th century CEO - What's good for MS, is good for the world.) There
is little reason to wonder why Mr B did what he did.

-ralph

I'm sure they could have done a better job on the conversion without
compromising the features of .net though. In terms of MS's budget I don't
think it would have been terribly expensive either.

Michael

Ralph,

Perhaps no one calculated the cost of thousands of irate developers not
adopting the .NET platform? An easy transition from VB6 to VB.NET would have
given a large push to the platform. Does that not have a dollar value?

Gary


Show quoteHide quote

Show quote Hide quote "Does that not have a dollar value?"

I am sure it does, and I am sure it did. As it must have come up during the
initial planning for the move to .NET, but apparently not enough.

Appreciate that providing a VBc 'bridge' to dotnet, would not have been as
easy or cheap as so many VB developers believe. It would have been a highly
unique and specialized project. It would have taken a lot of resources, a
combination of specialists, and a dedication to a principle of "VBness". In
short, just the sort of secondary revenue draining effort dotNet was
envisioned to 'replace'. And perhaps, more importantly, something that VB
itself has never, ever, really enjoyed.

I think it can be argued that MS NEVER understood VB. From its very
beginnings it was always more of a 'dancing bear' phenomena to them. They
thought it was cute enough when first released, but VBXs and the growth
industry that followed completely surprised them. Even when VB was the
primary development platform for Windows, they always seemed to give it
second-hand status - a pleasant accident - but that was likely not to last.
Ask any long-term VBer what they would have liked to see in VB and you will
come up with a list that 'started' 15 years ago, with many of the same items
still on the list. All items that could have been 'easily' implemented, yet
never were. Why?

[Someone brought up FoxPro, which makes an interesting comparison. It has an
amazing list of OOPL features. Features provided over the years by a much
smaller team with fewer resources - but apparently a team allowed to work on
their own with far less outside influence.]

As far as 'cutting off some heads', who in the company can even touch the
head of Mr. B? And as long as next quarter's profits are met, why would
anyone want to?

-ralph

in <iJ6dnRBSCPsYYsneRVn***@arkansas.net>

Show quoteHide quoteHow can you talk about revenue drain when their cash assets exceed 50 billion?
And what about the billions they've wasted defending their gorilla tactics
against their competitors.  And what about the billions they've wasted in
markets where they don't belong?  Yeah baby, that's all far more important than
caring for a customer base and the customer's assets.

---
Stefan Berglund

Show quote Hide quote I was being mildly sarcastic. Obviously somebody considered it to be
too-expensive for the return, or at least used that excuse to justify
dropping it. (At some point everything becomes a matter of money.) Which was
also often the case during the life of VBc for adding features.

There is no doubt MS could have come up with the money and resources if they
had wished to continue VBc. As you noted, in another post, it is quite
obvious that they did not. While I am convinced that dollars lie at the root
of the decision (as it is also a prime motivation for dotNet), it certainly
wasn't the only reason.

All the details will eventually come out. It will be interesting to see what
the future holds for MS.

-ralph

On Tue, 18 Oct 2005 14:00:28 -0500, "Ralph"
<nt_consultin***@yahoo.com> wrote:

<snip>

During the late 80's and early 90's there was a lot of MS 'sneering'
at BASIC

That got sorted out when B.G. went public stating that BASIC would be
the core scripting language for OLE automation.

A few words from the boss shut them up big time.

True - when a company forgets its past it often jeopardizes its
future.

MS made its money by tackling 'corporate' computing head on from small
relatively inexpensive computers programmed by 'little guys' that were
fast on their feet.

In essence, we bypassed the IT departments and produced working
systems - rather than man-year estimates.

Then networking started and the IT department crept back as network
administrators.

MS has become its old enemy

Show quote Hide quote VB/BASIC has always been sneered at, and as you noted both by 'outsiders'
and MS itself. I remember being in Redmond and listening to the rants
against VB by MS C++ developers and MS 'insiders'. (Of course the fact that
VB was shipping and we were still trying to get AFX/MFC to work seems to
have escaped notice. <g>) Even from the beginning VB was considered just a
'temporary' intermediate development tool.

I fully understood their position, because frankly VB is (was) just sooo...
wrong on sooo... many levels. (Need we iterate them all here? <g>) But it
did accomplish Mr. Cooper's goal of delivering a way to create Windows/GUI
applications for the adverage programmer. And it worked - again on so many
levels.

With all its obvious 'inadequacies' it is hard to imagine how VB became so
popular and why it has had such a dramatic effect on Windows. There are many
explanations - most of them dwelling on the "Beginner" part. But even then
it is hard to explain so many rather sophisticated applications that were
created with it. After all, surely 'intermediate' programmers would have
abandoned it, by the second delivery? <g>

This thing that VBc had - call it "VBness" - I'm not sure was ever really
understood by anyone. It almost seems like the common man's definition of
"Good Art" - "I can't describe it, but I know it when I see it."

I doubt if I have any more understanding that anyone else, but I think much
of VB's strength came from the fact it was a mutt. It was sort of OO, but
not pissy about it. It did "COM", but never so much you shot yourself in a
vital organ. 90% of anything you wanted to do was but a click away. Simple
error handling, almost mindless controls, straight-forward data handling,
and splice 'n dice with perhaps the simplest syntax possible. It brought a
lot of technolgies together and made them practically transparent.

Apparently, as one of dotnet's stated goals is to also bring programming to
the masses, MS thought they could position VB.Net in this role. I don't
think it is working. It may have similar syntax, but it pure dotNet, no
hybrid, no feet in another world, it lacks "VBness".

I believe MS is missing the point in not providing a 'mutt' for .Net. Not
sure what that creature would look like, but I'll know it when I see it. <g>

-ralph

J French wrote:
Show quoteHide quote "Microsoft has become what it used to mock," says Gabe Newell, a developer on the
first three versions of Windows. At late-night rounds of poker with "Bill and Steve"
in the mid-1980s, he says, "we laughed at IBM. They had all this process for
monitoring productivity, and yet we knew they had spectacularly bad productivity.
That's Microsoft now."
-
http://www.forbes.com/home/technology/2005/09/12/microsoft-management-software_cz_vm_0913microsoft.html

in <uY0EQMP1FHA.2***@TK2MSFTNGP15.phx.gbl>

Show quoteHide quoteFascinating reading, although this has been intuitively obvious to the most
casual observer for some time now.

---
Stefan Berglund

Stefan Berglund wrote:

I can't take seriously a writer who could produce this:

"The company relies on Windows and a suite of desktop applications -- products released a decade ago -- for 80% of sales and 140% of profits."

http://innumeracy.com/

Jim Mack wrote:
http://www.forbes.com/home/technology/2005/09/12/microsoft-management-software_cz_vm_0913microsoft.html
LOL!  Oh man, I musta glazed right past that.  (Is that how one goes about getting
onto one of their lists? <g>)

RW

http://www.forbes.com/home/technology/2005/09/12/microsoft-management-software_cz_vm_0913microsoft.html
Show quote Hide quote That would be a hard company to work for. I mean what would your quota look
like for next quarter?

-ralph

Ralph wrote:
Show quoteHide quoteI don't know, but I'll bet they expect a 110% effort.

in <#sCXBOZ1FHA.3***@TK2MSFTNGP15.phx.gbl>

I guess if you want to react that way I can understand because I refused to sign
my son's school progress report because it showed that he had scored in excess
of 100% in math and that's just not possible.

But as used in the article I would interpret it to be a poorly veiled literary
attempt at describing a situation in which the out go exceeds the in come.

---
Stefan Berglund

Stefan Berglund wrote:
Show quoteHide quoteAre they trying to say that -40% profits somewhere else (losing
divisions) are offset by this amount for a sum total of 100%?

Mike

On Thu, 20 Oct 2005 19:23:41 -0700, mscir <ms***@yahoo.com> wrote:

<snip>

Spot on:

   80% of sales generate  $  1.4x  (profit)
   20% of sales generate  $ -0.4x  (loss)

   100% of sales generate $ 1.0x  (Total Profit)

This kind of figures as new products (and unsuccessful products) are
likely to generate a loss.

mscir wrote:
Yesterday I ate 140% of a sandwich.

Jim Mack wrote:
Heck, I didn't say I liked it <g>, I was just looking for the possible
"logic" behind the statement. I fully believe the culture is in decline,
and one of the symptoms is a decline in literacy ("Twilight of the
American Culture" by Berman.) But usually I don't see it from
professionals, at least not that blatantly.

Missing some fingers?

-ralph

Or,

A really small sandwich, consumption of the plate and
napkins, and possibly a bite out of the table too...

A small sandwich and a couple bottles of 140 Proof...
http://www.jayski.com/jack/newtour.htm

A Charlie Distiller... http://encode.com/exec/npage2.htm

Sounds like a really good sandwich in any case.

Stefan Berglund wrote:

Maybe, but if so it was the only island in the sea of numbers presented in the article where any literary attempt was made. :-)

in <#531S860FHA.4***@TK2MSFTNGP15.phx.gbl>

I think what no one has realized yet is that Microsoft actually made a conscious
decision that they didn't want VB developers any longer.  How else can you
explain the situation?  I also think that the number that they put forth for VB
developers ( what was it ~6 million) was actually all part of their marketing
smoke and mirrors ploy.

---
Stefan Berglund

Show quote Hide quote I believe most VBers are well aware of that fact. It angers those with an
investment in VBc technology, annoys some, and it gives strength to others
to abandon VBc.

-ralph

There's a reasonable number here who think it's a poor language based on
very little knowledge.

None of this was in dispute.

Michael

¤ Those people in this group bagging .net are those who don't really know it.
¤ Anyone who's bothered to learn it seems to understand why it's superior.
¤ Sorry guys, I just had to say it after reading through a thread about why
¤ vb6 is better than dot net because someone couldn't work out how to change
¤ the startup form on their first day of using it and other similarly minor
¤ issues. :-)
¤
¤ Michael
¤

If you haven't noticed, this newsgroup is comprised mostly of diehard Classic Visual Basic
developers so I wouldn't anticipate many positive comments (or truths) concerning VB.NET.

In any event, Classic Visual Basic is suitable for some folks and that is why they have chosen to
stick with it despite the fact that it has no future.


Paul
~~~~
Microsoft MVP (Visual Basic)

True... no future... in fact, BASIC is dead, period. B# = pseudo code
version of C#, and nothing more. That's Ok as the company I work for is
finally starting to think about a VS update. I'll probably tinker with the
framework in B# but I doubt they'll let me actually write apps with it.
Especially when they realize the amount of effort it's going to be to do the
switch. No company is going to want to re-write everything every few years
so the best bet would be to stick with a language based on C which, as ugly
as it is, seems like it'll never die. Heck... there are even (ansi)
standards written for C... imagine that.

Think you've missed the point. Anyone who uses VB.NET can see that it
is a great dev environment.

But no-one is using it because:

Apps created using it will require a 25MB install. Therefore you will
have no competitive advantage against a 2MB app. Therefore your
business will fail.

Apps created using .NET run sloooooooow.

Developers would have to rewrite all their apps for no business
benefit. Therefore the business will fail.

You are a techie not a business person. That is why you will never be
able to understand.

<jameshamilton***@hotmail.com> wrote in message
Show quoteHide quoteMS is planning to manage all SPs, fixes, and installs. Newer platforms come
with the Framework. They expect the others to download the Framework as part
of their subscriptions, hotfixes, etc. .Net applications will become so
incrediably popular clients will be begging for installs.

The next platform will not only come with the Framework, but most of it will
have moved into the kernel and become part of the OS. Improving speed and
allowing vendors to only have to supply far smaller amounts of code.
(Remember the Framework supplies 80% of the functionality.)

Mr. B will be hailed as the technology innovator of the new millennium, and
Time's Man of the Year.

Anyway, I think that is the plan. <g>

-ralph

The problem with all of that is the same as it's been for the VB runtimes;
the users are frequently a version or two behind and you can never count on
them having the runtimes they need to run the app so you always have to plan
to deploy everything.  It all sounds good at the marketing level but quickly
falls apart in practice.

Show quote Hide quote Totally agree. I was trying to be facetious.

"One thing I noticed"* when the Framework first appeared in beta was that MS
had gone to great lengths to insure compatibilty with different versions of
the Framework. I was impressed. Followed all the rules...

I believe they 'broke' it with the 2 or 3rd installment. <g>

-ralph

in <WpmdnYG6Ro800MXeRVn***@arkansas.net>

Show quoteHide quoteOoh!  Ooh!  Where can I sign up to have Microsoft be the keeper and guardian of
all my assets since they've demonstrated such due diligence regarding my source
code assets.  Ha Ha Ha.

---
Stefan Berglund

<jameshamilton***@hotmail.com> wrote in message
I think you missed the point because you've gone and done exactly what I was
talking about in my original post. :-)

That's just plain wrong, people are using it. Look at the questions that get
raised in this group, there are almost no advanced questions left here.

Again just plain wrong. CDs hold 700MB and it can actually look better if
it's fuller, it gives the customer the impression you've done more work. VB6
apps take 10 meg or so anyway, not 2.

..Net apps do run a little slower but not that much. Startup is slower but
once it's running performance is quite good.

Plain wrong again. There is a benefit although it could be argued it's
minimal but this will not automatically lead to business failure. Existing
apps could be left in vb6 and new apps written in .net.

Actually I am both.

Michael

   So .Net is good for creating excessive bulk
to pad CDs? Why didn't you say so?! I thought
you were recommending it as a programming
tool.
     I happen to be looking for just the sort of
thing that you're selling. I need to create a 699 MB
padding file so that I can make an impressive,
professional-looking CD for my software. Do you
think I should use VB.Net or C# for that? I've heard
that the learning curve for making CD stuffing with
C# is rather steep, but I'm willing to stick it out if
C# stuffs it better.

Show quote Hide quote Very funny. The point was that most apps ship on CD so an extra 10meg out of
700 isn't going to make any difference.

Michael

Michael,

That's a great philosophy if your business is making little 'throw-away'
apps. I've been selling virtually the same app for nearly twenty years. What
do you suggest I do?

Gary

If there's the budget for a re-write and other possible reasons for a
re-write then re-write it. If not then leave it in vb6.

Michael

Michael,

That comment is the reason you shouldn't be giving these useless sugestions.
Practically all of us who are stuck in VB6 are stuck for the same reason.
Too much VB6 source code and too expensive to port.

If I've got one main application and I am going to still be selling and
maintaining that app ten years from now, and if there is no budget for a
re-write, that means I am stuck with VB6 for the forseeable future. It is
not a case of choice but of  ROI.

Gary

Show quote Hide quote And a large part, as it has been hammered on over 'n over - is why do the
port?

Is it to gain performance? All tests I have done have demonstrated dotnet
versions to be slower or 'just as good'.

Is it to gain some feature? Everything I have seen so far in dotNet is a
subset or 'just as good'.

There are some areas of dotNet that are handled a bit better - XML comes to
mind. But if you already have fought that war and have something that
works - what's the point? Its like telling someone with a new house, they
should tear it down and rebuild it, because they could have built it easier
and 20 days faster with different techniques and a different contractor.

-ralph

Ralph,

In my case, the only reason to do the port is not to get locked in the past.
Although .net has a lot of interesting things going for it, none of them at
present are absolutely necessary for the Windows development I do.

Gary

Show quoteHide quote

Usually I agree with most of what you say but this statement is the very
reason I started this thread. To say that everything in dot net is a subset
of vb6 is totally and utterly wrong. Dot net is far far superior to vb6.

Right, the difference between vb6 and .net boils down to better handling of
xml. ;-)

If the house never changes then you wouldn't tear it down, but if it was
being worked on constantly over the years getting bigger and bigger starting
off with bambo foundations and moving between technologies as they were
invented then it would get to the point where you would need to tear it down
and start over. :-)

Michael

Show quote Hide quote "To say that everything in dot net is a subset of vb6 is totally and utterly
wrong. Dot net is far far superior to vb6"

This is a difficult media and gets tougher as we drift into allegory.
<smile>

What I meant to convey was the fact that while I agree that dotNet offers a
really cool new development environment - as far as the finished product is
concerned - it really doesn't offer that much. There is no 'killer feature'.
There is very little when you're done that you can point to and go "Wow!"

I have a schizophrenic relationship with dotNet. As most would guess I am a
bit of 'shoot from the hip' OO bigot. I love dotNet. I have no qualms
jumping to the next job and playing with something new. I personally don't
have a large investment in legacy VBc code.

But my clients do. Few are OO bigots. Few appreciate "Let's do it this way
because it is cool". Most have a very large investment in 'legacy' code. Few
consider their applications 'bamboo huts'. (Frankly some are, many are not.)

It has always been relatively easy to go into a boardroom and pitch a MS
'upgrade' (VB4/5/6, MFC, ATL, COM+). DotNet is a tough sell.

Let me drift a bit farther - one of MS's competitors in the BoardRoom is
OpenSource. OpenSource's biggest selling feature is its independence from
"Vendor Tyranny". One could always counter this by pointing to MS's
exemplary record of maintaining backward-compatibiity. That argument just
got wipped out. I have had several clients that said - if we have to rewrite
why not just move to Linix/Java. (There are other reasons why this is a very
bad idea, but it is an move that in many cases in the past would not have
even been considered let alone adopted.)

Anyway, it just boils down to the fact that this issue is not a simple "Get
over it and move on". Wish it was. It is that simple for the guy with a
50,000 sqft house on a lake and for the lone wolf developer/shop, but for
everyone else in between - it has some impact on the pocketbook. Some people
consider that a poor return after 15-20 years of loyality.

-ralph

Gary Nelson wrote:

Exactly.  It is not usually a case of one or the other, in regards of
whether an application should be ported or not.  There are lots of
things that need to be taken into consideration.

At one of my previous employers we had two substantially sized products
written in VB6.  One of them would be too time consuming to port.  The
reason is not that it couldn't be done, but it could not be done in a
reasonable timeframe and for a reasonable amount of money.  The shop
runs with three developers, but they are continually providing
functionality updates and bug fixes.  They couldn't source a single
person, or even a small team to port the project, as it would require
bringing in a consultant or hiring on a new developer to ensure that
customization would continue to be made for customers in a timely
fashion using the "legacy" codebase.  At a large shop, doing something
like this is a little more trivial, because there is a higher chance
that the resources are available.  Small to mid-sized shops seem to
have a higher chance of running into this scenario and have been
squeezed out by the lack of a smooth migration path.  (Note, I didn't
say that there wasn't a provided migration path - just it could have
been put under a hell of lot more consideration.)

The other application is one that I had the luxury of doing the design
work on.  I based a large amount of the code to operate in a "plug-in"
fashion.  This took into account, being able to rewrite the "Operations
Engine" in .Net quickly and calling the old DLLs via Interop.  This
provides a means to gradually port the individual plug-ins during bench
time.  Since each plug-in was basically just a class, porting them over
was not nearly as daunting as it could have been.

In my experience, since .Net was initially released, is that the
applications that have a higher probability of being ported are
applications that exist in a shop of large resources (either
financially or staffing, usually both) or applications that were
written specifically with the nugget in the back of the mind that it
should be written in a way to ease in migration.  The problem is, that
while everyone knew that .Net was coming, Microsoft was saying
something to the effect of VB.Net being able to convert 95% of an
existing VBc application.  It worked, in theory, with mid-sized
projects.  Usually, though, the larger the project, the more under 95%
that number went.

People with older projects that are highly used, which Microsoft
grossly ignored, are less likely to be ported.  People who have written
applications fifteen years ago did not plan on being left out to dry
if/when there was such a large change over such a short period of time.

Just my two cents.  ;-)

Joseph

So you plan to sell an app for a 30 year period without a rewrite? I'd
expect to do a full rewrite every five to ten years and I have trouble
seeing how there couldn't be the budget for it. Surely after having the same
source for 20 years it's in need of a major overhaul. You could just release
a new version and charge your existing customers for it. In my experience
this has always been hugely successful, the customers have welcomed it and
it has generated a huge amount of revenue. It's like making every sale your
business has ever made all over again in a short period of time.

What I don't understand is how you could have not done a full rewrite in the
last 20 years, did we even have windows in 1985? :-)

Michael

Michael C wrote:
A lot of guys who were too young to remember have that same trouble, yeah.

MSBasic has been around since 1976.  Windows, from this perspective, didn't come into
the picture until 1991.  Well-designed business logic migrated without issue, and in
fact *still* loads just fine into VB6.

I just can't see an app written in 1976 not needing a mojor rewrite, it must
still use a text file probably loading all the data into memory in one go,
dumping it all back to the text file in the end with no network support. And
that's just one part of the app, I can only guess at the other sins that
must be under the hood.

Michael

Michael C wrote:
Fwiw, I tend to agree.  But that's irrelevent.  The decision *must* remain with the
developer, *NOT* the language vendor.  Saying, "Break my code!", is the coward's way
out of facing their own self-imposed reality.

Well, that's just ignorant supposition.

I wouldn't; you're not showing any particular talent in that area. ;-)

The desicions is still there, you can continue to use vb6 :-)

I can see why they made .net incompatible with vb6. Making it compatible
would have hobbled it too much. But they could have made a better effort at
an upgrade utility.

Quite possibly but I can bet fairly accurate.

Michael

Michael C wrote:
Not if you want to use the latest tools.  Duh.  How silly do you want to make this?

That's the kool-aid talking.  You've chosen to believe lies.

Absolutely.  And it would've been *massively* easier to do so, were there not so many
gratuitous incompatabilities introduced.

Extremely unlikely.  Folks who do have 20 year old code bases have been twiddling
them that whole time.  You seem to be thinking "all or nothing" are the only two
choices.  Ain't so.  Good designs migrate well and relatively painlessly when
languages are thoughtfully upgraded, but not necessarily to different/new langauges.
See the difference?

That's just the reality of the situation, similar to when dos went to
windows some major changes were required.

No way! After using vb6 and dot net for a while you see why they made the
changes they did.

Yeah, but hobbled the new language with vb6 style crapulence.

I always find that when you get into these sort of conversations everyones
got this perfect apps that been well designed and would have migrated well.
The reality is always different though and after many years of modifications
most of the apps out there would have gotten to the stage of benefitting
from a full rewrite. Even MS with all their billions of dollars got to that
stage with vb6 :-)

Michael

On Tue, 25 Oct 2005 11:25:46 +1000, "Michael C"
<mculley@NOSPAMoptushome.com.au> wrote:

Show quoteHide quoteThat's just a cop-out.  You can't tell me that all of the Office apps
aren't in exactly that same state, however, you don't see MS having to
"rewrite" them (meaning "from the ground up", as you suggest is a
*must* every 5 years).  In fact, most of the Office apps still contain
code from the 16bit Windows days!  (Imagine that!)

As Karl says, you've just had too much koolaid so that now you believe
the rest of the crapola they're feeding you.  ;-)

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'tspam@mvps.org

I never said it was a *must* and I never said every 5 years, that's
something you made up. I said every 5 to 10 years it *can* be a good idea to
do a rewrite. 5 years is probably too soon but as you get towards 8 years
you start to get to the point that there's too much fix to make it worth
continuing on the existing code. Of course this will vary from app to app
but as a general guide I've found this to be true. Of course everyones going
to chime in and say how perfect their apps are that have had close to a
decade of reworking from many different staff but in reality it's very
rarely like that. Most of the apps that I've looked at have been much more
heavily weighed down by the sins of the past than mine.

Do you have some proof of that or are you making that up too?

I think I'm just the only one who'se moved over to be silly enough to be
arguing in this ghost town.

Michael

On Tue, 25 Oct 2005 14:39:55 +1000, "Michael C"
<mculley@NOSPAMoptushome.com.au> wrote:

Here's your exact quote:  "I'd expect to do a full rewrite every five
to ten years"

To me, that sounds a lot more like you consider it a must than the "it
*can* be a good idea to do a rewrite" you are now claiming to have
meant.  It's always better to just come out and say what you mean in
the first place and save all of the misunderstandings.


It is fairly common knowledge and I've heard/seen it stated publicly
from various MS sources.  I'll troll around and see if I can dig up
any cites.

Clearly, you haven't "moved on", if you're still here.  There may be
hope for you yet!  ;-)

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'tspam@mvps.org

Actually, writing "I'd expect" sound more like can than must to me. By
saying "I'd expect" I'm expressing an element of doubt. You really did twist
what I said by changing it into "must do a re-write every 5 years". Of
course it varies from app to app, in some cases it might make sense to leave
something in dos. The apps that it wouldn't make sense in are those that
aren't moving anywhere anyway.

Ok. Make sure it's not something there for compatibility such as DDE etc.

I'm not coming back, I've just gone from 5 days a week down to 2 to get away
from vb6.



Show quoteHide quote

Michael,

Have you actually done that? Do you have 5 to 10 years experience (or more),
and have you already done one or two  rewrites on major projects?

Gary

Yes, I wrote an app from 1995 to 97 and have been rewriting it in dot net
over the last 2 years. I'm very happy with the result and am glad I did it.
Another project I started in 1999 I wanted to rewrite but I didn't get the
go-ahead. This is for 2 different companies, I'm heading away from the one
that didn't want the re-write. :-) I was programming professionally in a lab
a few years before that, I can't remember the date, probably 1992. I started
programming as a hobby 23 years or so ago on a microbee.

Michael

Michael,

It's kind of funny. About two weeks ago a client pointed out a bug in the
business logic of a certian calculation in a module I did for our main app
back in 1998. The bug had survived for over seven years without being
noticed. How many bugs like that does a rewrite introduce? Particularly in
very complex applications.

If instead of being an employee, you were an employer you would have a
different attitude.

Gary

That's how one my employers thinks. He's going to spend a significant amount
of time doing major modifications to an existing app when I quoted a full
rewrite in dot net as being 25 to 50% longer. He's going to end up with an
inferior product and need to do a rewrite into dot net over the next few
years anyway.

Michael

Michael,

Your employer thinks that way because he is an employer. If he breaks the
bank he is out of business. You, as an employee, have a lot more liberty. If
your employer goes bankrupt, it's no big sweat for you, just find another
employer, but for him it's all he's got.

As to your  quote of a full rewrite being 25 to 50% longer, would you be
willing to cover the cost overrun with your wages if it goes over that?

Gary

Thing is I've done 2 rewrites for he before and both have been very
successful. The money is definately there and the project would definately
be a success.

Depends if he was going to give me some of the millions he takes home each
year then I would.

Michael

I forgot to mention I've also done 2 rewrites for dos apps into windows for
one company and both were highly successful. I didn't write the dos apps
though.

Michael

Show quote Hide quote That is a wise decision.
1) General observation - the ones making the best and quickest transition
are the individuals and shops that go and don't look back.
2) The hardest thing in developing is a context-shift. It is often subtle,
but it impacts productivity. I put switching back and forth from VB.Net and
VBc as harder than doing VC++/VBc. I think because if you don't play
attention you tend to make invalid assumptions in dotNet as the language
looks so similar. At least with C++ - one look and you KNEW you weren't in
Kansas anymore. <g>

-ralph

Michael C wrote:
Dude.  How many rows/columns does Excel support?

Or the number of rows allowed for a table in Word.

I did a little bit of searching but didn't come up with the "golden
quote" I was looking for.  Never the less, there is plenty of evidence
that there is still 16bit code in Office.  If it's so necessary, how
come we don't see MS doing your 5 to 10 year rewrite schedule on
*their* bread & butter code base?

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'tspam@mvps.org

Hardly proof, they might store the row *and* column position of each cell in
a 32 bit int.

Michael

Believe what you like.  However, if you truly had the programming
experience that you claim to have, you'd know this for what it is...
sections of the app that haven't been rewritten since the 16bit days.

Bryan
_______________________________
Bryan Stafford
New Vision Software
newvision_don'tspam@mvps.org

each cell in
In addition, would Microsoft **really** have originally stored the
row and column in two separate 16-bit integers back in the 16-bit
version of the program and then rewritten **everything** for the
32-bit version just so they could maintain the 16-bit limitations
on the row and column by combining these two items into the same
32-bit integer for storage? I'm thinking... Not!

Rick

The experience I have brought me to that conclusion because I've seen MS
store 2 16 bit numbers in an int! It might have been a space saving exercise
and is definately not *proof* they have 16 bit code left.

Michael

Michael,

Some yes, but certainly not all of them.


Beauty is in the eye of the beholder.

Show quoteHide quoteBecause MS has billions they can do it. They can even afford to alienate a
large portion of their customer base. I don't have the billions, and I care
about my customers.

Gary

On Tue, 25 Oct 2005 11:25:46 +1000, "Michael C"
<mculley@NOSPAMoptushome.com.au> wrote:

<snip>

B*ll*cks - VB6 is just a slightly enhanced version of VB5

Also, re-writes are not necessary if one uses 'gentle migration'
techniques

I've been coding since 1977 and have only ever done one major
re-write, and that was porting a fairly complex DOS EXE (not system)
to Windows - and even then that was 90% cut and paste.

Sure, sometimes one looks at a minor EXE and decides that re-writing
it is simpler than piddling around inside old code
- but that is not re-write

I meant vb6 needed a rewrite so they did dotnet.

You can do the cut-n-paste into dot net, i've done a couple of dlls that
were just a line by line translation. It doesn't take that long and that was
from vb6 to C#.

Michael

I think you'll find it was more likely that Anders Hejlsberg had some
pretty fixed objectives

I've done cut and paste from MSDOS Basic to Delphi
- pretty painless

I don't particularly object to Dot Net, it is probably quite a sound
concept for large corporate systems, especially servers.

However I really object to them abusing the name 'Basic' and
pretending that it is an 'upgrade'

Also I resent the fact that they are shunning the smaller 'fast on
their feet' developers, who actually made MS's fortune in the first
place.  Without us people would not have bought computers, and MS only
got into writing non-joke like applications pretty late in the game.

Michael C wrote:
There you go again.  Fwiw, I pulled the code to directly read/write DBF files from
<gasp> an old QB4 module, into VB6, just a few months ago.  No need to rewrite
whatsoever.  I just dusted off a few variable names, to be more descriptive, and away
I went.

If *you* required "major changes" in moving non-UI code from DOS to Windows, that's
*your* problem.  Many folks actually understood programming concepts back then,
however, and managed just fine in that relatively painless transition.

Show quote Hide quote He's already stated that he codes so as to require a full rewrite every five
to ten years.  The ones to feel sorry for are his employers and/or
customers.  They are obviously paying for a lot of wasted time.

Bob Butler wrote:
Yeah, I haven't met a .NET devotee yet who's what I term an "application owner."

Show quote Hide quote Nope.  Seems to be a boon for consulting-types who get to recommend rewrites
frequently and pump up the billable hours by recreating that which already
exists using the latest gee-whiz fluff rather than long-term maintenance and
extension of apps.  It's such a pity because both could have been supported
if MS had given a damn about it.

Show quote Hide quote Yeah yeah, as I said in these sort of conversations in newsgroup land apps
always become magically perfect and easy to port, everyone wrote everything
all componentized and didn't do any hacks. I've always been fairly negative
when looking at my own code a few years later but after looking at other
peoples I've realised mine is actually not bad. It just gets to the point
where the features that want to be added add up to more time than a rewrite.

Imagine if MS tried to slowly port vb6 over to dot net over the years, dot
net would have been severly hobbled. But I don't know why I'm here arguing,
I'm in the company of those who are holding onto vb6 to the grim end, only
those who are dead against rewrites are left here :-)

Michael

Show quote Hide quote Previously, applications evolved over time; sections could be rewritten to
take advantage of newer possibilities while still being integrated into the
whole.  The "same" app at the end of 20 years might have relatively little
original code but at no point would it have been rewritten.  It would have
been great to be able to bring a VB6 app into dotnet and then begin
replacing pieces over time as need dictated and resources permitted.

Instead, the choice now is to halt the evolutionary process while the entire
body of code is redesigned and rewritten or hack it by trying to wedge
dotnet components into the mix and having a Frankenstein's monster instead
of a coherent design.

MS blew it big time by not providing a real VB language within the dotnet
framework.

Show quote Hide quote Aren't you being deliberately obtuse, just a tad. <g>

I have an application that doesn't date back that far. Only from around '93.
But looking back still looks like the Stone Age. (It once had controls
written with the CDK.) It is a package whose essential business rules have
not changed in all that time. Does it still have the same code? Certainly
not. It has changed dramatically through the years, sometimes weekly. But I
would never consider it as having gone through a major "re-write".

There is a big difference between going in and modify (repair, improve, etc)
pieces of working code to meet changing needs and completely re-writing the
program to satisfy a whim.

I am currently porting it to dotNet (and that is a re-write), but more as a
learning tool that anything else. If the 're-write' had to pay for itself
(ie, if my wife knew about it. <g>) it wouldn't happen.

-ralph

Less so than most of those fighting to hold onto vb6 :-)

I see it as part of the life of an app, you modify it for X years and then
do a rewrite, adding a bunch of features that would be difficult or
impossible to add by modifying it. If you're app is not up to that stage yet
then stick with vb6 until it is.

Michael




Show quoteHide quote

Michael,

By the way, I didn't say 1976. I said twenty years ago, which would be 1985.

You certainly come to some very strange conclusions. Exactly how do you load
all the data into memory when all you have is 128K RAM? You know, when you
don't know what you're talking about it is best not to speak up.

Sins?

Karl said 1976, I was responding to him.

Dodgy code that's had dodgy fixes done to it to fix it's original dodgyness.
Or possibly good code that's had dodgy fixes. Or possibly dodgy code that
hasn't been fixed. The sins might have been comitted by a third party and
can't be fixed.

Michael

Michael,

Why not? Haven't you heard that saying: 'if it aint broken don't fix it'?

http://www.joelonsoftware.com/articles/fog0000000069.html


When you have a very large program you overhaul one thing at a time, not the
whole project. Rewriting the whole project is the best way to go bankrupt
that I can think of.

Excuse me but that sounds extremely naive. Most of my customers don't know
the difference between a .net and a baseball bat. Customers would welcome a
rewrite, only if it meant new funcionality that made their user experience
better. How on earth can you do a full rewrite AND add new funcionality at
the same time?

You aren't Dilbert's boss, are you?

The original program was written in gw-basic for MSDOS, although we also
ported it to CPM/86. From there to the original BASIC Compiler, to
QuickBasic 2.0, 3.0, 4.0, 4.5 to PDS 6.0 to PDS 7.0, 7.1, to VB1, VB2, VB3,
VB4, VB6.

The closest thing to a rewrite was the port to VB1 as the user interface had
to be rewriten. But the business logic largely remained the same. In fact I
could show you sections of our source code that have remained largely intact
across the different versions.

Gary

I'm sure I could find things that are broken :-) I know all software
suddenly becomes perfect in these sort of discussions and there's absolutely
no sins from the past sitting in there :-)

"Is software supposed to be like an old Dodge Dart, that rusts just sitting
in the garage?"

He makes some good points although I think software does "rust". It does get
old and crappy just by sitting there and you get to the point where it will
be easier and quicker to do a re-write than fix all the problems in it.

If poorly managed, sure but a company should be able to manage this after 10
years in business.

Depends on your app and your customers. Customers of one of the companies I
work for have been screaming for the sqlserver version. As for C# they
probably couldn't give a stuff but when it comes with new features they do.

That's the whole point, it's *so* much easier adding new features during a
rewrite. You can take all of those features that have not been done because
it would have been a significant amount of work and take them into account
from the start. For example, converting an app from using an msaccess
database to using sqlserver might be a lot of work as an update but in a
full rewrite it is a simple decision and takes *zero* extra time. Find a few
big features like this and the customers will be itching for the new
version.

Sounds like a rewrite to me. I could show you sections of a completely
rewritten app that looked intact across a rewrite :-)

Michael

Show quote Hide quote Right before that sentence.....

"The idea that new code is better than old is patently absurd. Old code has
been used. It has been tested. Lots of bugs have been found, and they've
been fixed. There's nothing wrong with it. It doesn't acquire bugs just by
sitting around on your hard drive."

thoughts were released on Tue, 25 Oct 2005 08:26:54 -0700
bearing the following fruit:

Show quoteHide quoteShh! I've been telling my boss that that is exactly how bugs
get into the software....



Jan Hyde (VB MVP)

Ken Halter wrote:

And this makes perfect sense.  I was subcontracted to Honeywell a few
years ago and they had a very large legacy codebase with no intention
to re-write it for the sake of taking "advantage" of a newer language
or platform.

They actually had scoped out moving (at the time) to a Visual C++
version of their software on Windows 2000 from C++/COBOL on an AS/400.
Not only was the return on investment too low, the total cost of
ownership was higher and the one application that they did port over in
a feasibility study for migration performed a lot worse than the code
that was written in 1989.  Considering it was a complicated engineering
application that already took a sizable amount of time to render its
output, the choice was easy for them to make.

I use .Net at work now, although I still use VBc at home.  Classic
still has the R in RAD.  ;-)  I just wish that people would quit trying
to tell everyone that they need to move to .Net.  It is not the truth,
in any way, shape, or form.  Things are not always just in black and
white, as people like Ken and Karl have pointed out multiple times.

Joseph

On Tue, 25 Oct 2005 08:26:54 -0700, "Ken Halter"
<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:

<snip>

True, but with one caveat, most of the 'bugs' I've have of late have
been down to subtle differences between Win 9x and 2k/XP  the nastiest
was an error in XP's MSDOS emulation which broke a 15 year old
routine.   Int 21h, 17h  FCB rename file - the canonical way to rename
a volume label.

Michael,

?

Again, you say this because you are an employee and not an employer.

Show quoteHide quoteYou must work on very simple projects...


Cutting and pasting is not rewriting...

Gary

I run my own business 3 days a week and work as an employee for someone
else. I don't hire anyone although I've had a contractor do some work.

Hardly. The last project was a 300 form monstrosity with a web and pda
component.

The point is I could show you sections of a full rewrite that are basically
the same code.

Michael

Michael,

If it is basically the same code, why in the world would you rewrite it?

Gary

Some of it is the same code, a full rewrite you might not completely rewrite
100% of the code.

Michael

Not at all. I remember sitting down with my boss once and he asked me what I
wanted to do, rewrite a dos app into windows or start a brand new project. I
said to him are you crazy we've got an instant 500 customers for the
existing app. We rewrote it and got 400 sales in a few months, basically
making pretty much every sale the app had ever made again in a short space
of time (it took a year or 2 for the stragglers). He was most happy.

Michael

"Michael C" ...
Lovely story.  I remember the days well.

Windows *was* a very compelling platform to end users!

What's the selling point for the .NET "platform" shift?

GimmeAbreak...

In my specific case I've got lots of features that are selling points for
the new rewrite. There's so much more that dot net can do that vb6 can't
it's easy to add new features.

Michael

Show quote Hide quote Whereas, with DOS->Windows, customers would accept "upgrades" that didn't even do as
much, just to get into the new interface.  You lose.

That's true, you have to do more work now to get customers to pay again for
a new version.

I wouldn't say that.

Michael

Michael,

Which takes us back to base one. If you have a very small code base, you can
rewrite it AND "do more work". If you have a large code base there is no way
you can even get out a first version with equivalent funcionality, much less
"do more work" and add on new funcionality.

Gary

Yes you can. It's so much easier to add those difficult to add features in a
full rewrite.

Michael

Michael,

Imagine a full rewrite takes 18 months (just to get equal funcionality to
your old app). Are you going to hold back releasing your product for another
six months to get the new funcionality?

In the meantime your company will have gone bankrupt, so you can forget
about the new funcionality.

Gary

You've got the wrong idea of how to do a rewrite. The main idea is to take
all of the features that are too difficult to add and take them into account
from day 1. The app I've been working on mostly in the last few years needs
some changes to the basic data structure. Changing this would be very
difficult because it would effect most areas of the app. But with a rewrite
it's very easy. Just by doing this I get new features.

It's that simple is it? :-) With minor updates I don't see why the income
stream would change that much. You might lose a few customers and sales but
not many. Companies have had apps remain basically unchanged for much longer
than 2 years and haven't gone bankrupt.

Michael

Michael,

It sounds like you had a poor design to begin with. On the other hand,
perhaps the structure of your apps is nothing like mine. Mine have
innumerable modules each with very complex business logic. Each module was
developed in close connection with the clients who use it so as to get it
right. In most cases I don't remember exactly what they do, which means that
to do a rewrite I either have to study the code, line by line, and rewrite
it, and hope I get it right, or get back into contact with my clients to
have them go through the process again.  Either way it is a long drawn out
process. Especially when the module works fine and no one is asking for it
to do anything new.

Gary

You've got code for 1 customer? I would rewrite that. :-)

Michael

Michael,

Perhaps I didn't explain myself well. I have to find one of my customers who
is an expert in that particular subject, and ask his asistance to make sure
it does what it is supposed to. Many customers then use that code, but most
are not experts in the subject and don't know exactly what goes into it.

Gary

<snip>

Actually I've got quite a few cases where the customers prefer the DOS
App
- if something does exactly what they want a sensible punter will not
go in for 'change for changes sake'.

In one case I had to force a customer into a DOS -> Windows re-write
because the App had grown so much that I was having major problems
with memory (it was a touch screen graphical App started in 1990) and
the code was getting so tight that only I could maintain it.

With the benefit of hindsight I should have scouted round for a 32 bit
console mode compiler and used WDOSX, then made friends with the
people who write the CE DOS emulator - Win CE machines are a lot
cheaper, faster and more robust in terms of OS and hardware than their
Win9x/XP equivalents.

The customer is very happy with the software (it looks just the same
but with colours rather than monochrome), but the hardware is an
expensive nightmare ( I explicitly recommended NOT using the
hardware).

ROTFLMAO

Ignorance is bliss hey? :-)

Michael

Nope! Your original statement was just extremely funny.<g>

Rick

Strange, it wouldn't raise an eyebrow in a C# group.

Michael

Of course not... they're drunk on that same kool-aid. My question earlier in
this thread stands.... no one... not you, no one from MS, no one from any
group I've asked has provided *real* reasons dot net is the way to go for
new desktop apps. Dotnet for Web and mobile? Yep. Desktop? Still can't see a
reason.

The reasons are more subtle than the change from say dos to windows but that
doesn't mean they don't exist. I think interop is one very good reason,
especially in the type of apps I do working with directX, WIA etc. The fact
that you can create a large number of objects is another *very* significant
reason (vb6 had trouble creating too many instances of objects). The oop
features and strict type casting are other good reasons. Just the way it is
all consistant is another good reason.

Michael

Show quote Hide quote The "you can create a large number of objects" excuse is hardly a
significant reason, assuming it is even true. Just because you can do
something is never a good reason for doing it. Witness the large number of
pleas for assistance this newsgroup gets on the subject - "Help! My app dies
when processing a 5 gig file.", "Help! My app won't compile with 1100
options buttons.", &etc. I believe you will discover any desktop app with a
"large number of objects" has other issues far above any imagined
limitations in the language used to build it.

-ralph

It's definately true. VB apparently uses 100 bytes per object as an absolute
minimum while dot net uses 8 bytes minimum. It also doesn't have ref
counting which slows down vb6 considerably.

I wrote a grid usercontrol in vb6 that had 1 object per cell. It worked
quite well in most regards, vb6 was very quick at calling the windows APIs
to paint the grid so it redrew and scrolled very fast. The problem was
creating and destroying objects in vb6 is very slow so if the grid had 100
rows by 100 columns that came out to 10200 objects. This was really too many
objects for vb6. When I rewrote it in dot net the speed difference was
amazing, you could create a huge number of rows and columns in no time.
Having a lighter object really frees things up and allows you to define an
object for much more trivial items. You no longer have to think "is is worth
creating an object for something so small" you just create it. For example,
items in listboxes are now objects.

Michael

Show quote Hide quote Illustrates the difference between accessing a 'struct' (block of memory)
compared to accessing a COM object.

I have to agree that such situation might provide reason enough to 'switch'.
But it also illustrates why most VB6 desktops apps don't take that approach.
<g>

-ralph

Comparing a design that is inappropriate for VB6 against one that dotnet is
optimized for says much more about your limitations than those of VB6.

Maybe I was at fault for chosing the method I did but the fact still stands
that this is a big limitation of vb6 and an excellent feature in dot net.

Michael

If so you must be one happy camper!

Michael,

Can you name some of these things that you can do in .Net that you can't in
VB6?  Not stuff that might be easier to code, but things that are
_impossible_ in VB6 and possible in .Net

To start you off I've thought of a couple the other way around:

* Support older Win32 platforms

* Edit and continue, which is an example of just how easy it is for
rewriting and adding new features to be done simultaneously.  The IDE was
re-written and the feature "lack-of-edit-and-continue" was added.  To be
fair this comes back in VS2005, but 3 years is a long time without one of
the most useful debugging tools MS have produced.

* Share files from one project to another.

It's just as easy to add new features in the idealised perfectly-managed
apps that you seem to think are the only ones that count.  It seems to me
the you are the one with rose-tinted spectacles:

"
One thing _I've_ noticed is:

1) Those who play down the problems involved in migrating apps from VB6 to
VB.Net tend to have the least experience of doing so.

2) This thread and the ".NOT - My views" thread have far more posts than any
others on this board.

OK so that was two things I've noticed :)

Stewart Becker

Big deal, this concerned me when dot net first came out but not any more.
It's actually a good thing to get rid of win95 customers. Not that I've been
able to find any over the last few years. :-)

I thought you said things that were impossible, not just things that made it
easier. If you want to talk about things that are just easier I could list
literally hundreds.

You can't do this in dot net?

I think you've misunderstood what I'm saying. You might have a feature you
want to add but that will require a major change to the database, which will
then require major changes to a number of areas of the app. This amount of
time can easily become too large for the benefit of having the feature. But
if you are doing a rewrite this feature can be added for free, or at very
little cost (over the cost of the rewrite). Add a few of these features
together (we've got plenty) and it can be cost effective to do a rewrite.

Or have done it and know it's not as much trouble as expected. :-)

As for things that are impossible in vb6 that are possible in dot net how
about com interop. Although vb6 is a com language (possibly "the" com
language) it's actually very poor at working with com objects that don't
support late binding. I never realised but windows has hundreds, probably
thousands, of com interfaces that vb has no access to. This opens up all
sorts of functionality that's not available to vb6, such as direct show,
direct sound etc, cd burning using IMAPI, windows image aquisition and a
whole lot of shell functions.

Michael

Same old reply from the Kool-Aid crowd.... *we* don't use it so it must die.

Huh ? VB6 can already interact with DX8 and below, although MS
puporsefully did not add support for DX9/VB6.

It does on a *very* limited basis.

Michael

This attitude doesn't surprise me, since the whole VB6/.Net issue stems from
the idea that upgrading for the sake of upgrading is fine, and those who
don't/can't are irrelevant.  Some of us do have NT4 and Win9x customers that
we want to support.

Edit and continue is not possible in .Net.  I admit that it's a compiler
feature, not a feature of my apps, and it exists purely to make my job
easier.  I mainly mentioned this to highlight the fact that complete
rewrites tend mean that you remove existing features, rather than adding new
ones in.

No, each project's code exists in its own folder.  If you try to add
something from outside, it will take a copy and put it in the folder, so
that updates in the original file no longer occur in the other.  (If I'm
wrong on this BTW, and you can share code this way then let me know because
every method I've tried has resulted in multiple copies of a file, rather
than shared code.)  Now some may say that .Net's way is good since you don't
break other projects inadvertantly, but it has its uses for code-reuse.  In
VB6 (and other VS6 projects for that matter) _I_ am in control of where
these files come from - because the IDE considers me responsible enough to
deal with any sde-effects my changes may have.

No you've missed my point, which is that you accuse everyone else as having
a idealised hypothetical apps which are perfectly written in modules and
components, but then bring in the idea that companies must be so well run so
as to be able to absorb the cost of a re-write.  That is just plain
inconsistency.  Some companies will fold because they can't afford the cost
of a re-write, and to compete successfully requires being able to use the
new features of .Net compilers - but this doesn't mean they are poorly run -
just that they can't spare the resources involved for a rewrite that
wouldn't be necessary if they could use new features provided by .Net in
their apps as they exist now.  However that doesn't matter, as MS has
decided it doesn't need these companies' custom.

Stewart

The problem I've found with win95 and even win98 machines is that they
require so much work that's it's uneconomical to maintain them. I always
give people warnings that fixing these machines can easily run into the cost
of an upgrade. If you fix one thing another seems to break. This is probably
not the fault of win95 entirely but the age of the machines on which it's
run. Most of these machines you'd have trouble selling for $50 so it doesn't
make a lot of sense to spend labour on them when an hourly rate is higher.

I admit edit and continue is an awesome feature in vb6 and I would never
attempt to say I don't miss it. But there are literally hundreds of features
in dot net that compensate for it. I remember a little while after
installing dot net that if you had a single line if statement that you could
put a breakpoint on the if part of the line or just one the code that
executed if the condition is true. That really suprised me and showed the
depth to which they've gone with dot net.

Looks like you're right.

Fair point although all the companies I've worked for the money has been
there and they could have made more money out of the all new version but
they just haven't had the guts to spend it. I guess it is a risk and it
could be bad if it goes wrong but it could also be very good if it goes
right. The companies I've worked for have ranged from big to small but
mostly small.

Michael

I've seen that statement so many times it's getting real old. What, exactly,
is it that dot net can do that VB6 can't. Remember that you're posting to a
group that's full of people that have years of classes/modules built up in
their libraries so none of the usual "this feature is built into the
framework so you don't have to write it" arguments matter at all (not even a
little). The *only* good uses I see for dot net are web based and mobile
apps. Desktop users want performance..... which is one reason it took so
long for DOS to die in the first place.

¤ > In my specific case I've got lots of features that are selling points for
¤ > the new rewrite. There's so much more that dot net can do that vb6 can't
¤ > it's easy to add new features.
¤ >
¤ > Michael
¤
¤ I've seen that statement so many times it's getting real old. What, exactly,
¤ is it that dot net can do that VB6 can't. Remember that you're posting to a
¤ group that's full of people that have years of classes/modules built up in
¤ their libraries so none of the usual "this feature is built into the
¤ framework so you don't have to write it" arguments matter at all (not even a
¤ little). The *only* good uses I see for dot net are web based and mobile
¤ apps. Desktop users want performance..... which is one reason it took so
¤ long for DOS to die in the first place.

I think you answered your question. You can't build a web app. You can't build a native Windows
Service. You can't build a web service w/o the aggravation of dealing with SOAP. You can't build a
free-threaded application and any multi-threading requires writing a half-baked and faked threading
model. Absence of full OO support.

I could go on, but I'm not sure why you even bother to ask the question?


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote Well... web apps, services, soap, etc, don't interest me. I build desktop
apps.... poking around the dot net groups tells me that this "full OO
support" that B# claims to have is "half baked" in itself. Ever tried visual
inheritance for example?

VB6 supports inheritance, if that's what all the OO hoop-la is about.

Inheritance Class Generator: VB6 Add-in
"I'd call it a design that supports the feature in question. End of story.
Understand that inheritance is a purely abstract concept. If a design maps
onto the concept, it is "real", and anyone who says differently, is confused
by the difference between a concept and a given implementation of a concept
in some product. Please note how much of the code in this example has a
boilerplate quality. Not only can VB6 "do inheritance", but one could argue
that the VB team could have added the keywords to the language in a few
man-weeks of effort"
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=53587&lngWId=1

¤ > ¤ I've seen that statement so many times it's getting real old. What,
¤ > exactly,
¤ > ¤ is it that dot net can do that VB6 can't. Remember that you're posting
¤ > to a
¤ > ¤ group that's full of people that have years of classes/modules built up
¤ > in
¤ > ¤ their libraries so none of the usual "this feature is built into the
¤ > ¤ framework so you don't have to write it" arguments matter at all (not
¤ > even a
¤ > ¤ little). The *only* good uses I see for dot net are web based and mobile
¤ > ¤ apps. Desktop users want performance..... which is one reason it took so
¤ > ¤ long for DOS to die in the first place.
¤ >
¤ > I think you answered your question. You can't build a web app. You can't
¤ > build a native Windows
¤ > Service. You can't build a web service w/o the aggravation of dealing with
¤ > SOAP. You can't build a
¤ > free-threaded application and any multi-threading requires writing a
¤ > half-baked and faked threading
¤ > model. Absence of full OO support.
¤ >
¤ > I could go on, but I'm not sure why you even bother to ask the question?
¤ >
¤ >
¤ > Paul
¤ > ~~~~
¤ > Microsoft MVP (Visual Basic)
¤
¤ Well... web apps, services, soap, etc, don't interest me. I build desktop
¤ apps.... poking around the dot net groups tells me that this "full OO
¤ support" that B# claims to have is "half baked" in itself. Ever tried visual
¤ inheritance for example?
¤
¤ VB6 supports inheritance, if that's what all the OO hoop-la is about.
¤

VB 6.0 supports "interface" inheritance, not native code or "implementation" inheritance. You have
to implement delegation using code instead. Visual Basic.NET has native support for both.

What is it that you find to be so difficult with the visual inheritance support in WinForms and
Visual Basic.NET?

While you may not care about the missing features I mentioned in VB 6.0, many do. It doesn't prevent
you from developing applications that satisfy your requirements.

¤ Inheritance Class Generator: VB6 Add-in
¤ "I'd call it a design that supports the feature in question. End of story.
¤ Understand that inheritance is a purely abstract concept. If a design maps
¤ onto the concept, it is "real", and anyone who says differently, is confused
¤ by the difference between a concept and a given implementation of a concept
¤ in some product. Please note how much of the code in this example has a
¤ boilerplate quality. Not only can VB6 "do inheritance", but one could argue
¤ that the VB team could have added the keywords to the language in a few
¤ man-weeks of effort"
¤ http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=53587&lngWId=1

Nice rationalization. The problem is that the implementation still requires delegation code.  VB 6.0
doesn't support "overloading" or "overrides" either, although I'm sure you could find some way to
fake it as well.


Paul
~~~~
Microsoft MVP (Visual Basic)

Not me.... people that actually try to use it.

Visual Inheritence Sux
http://groups.google.com.my/group/microsoft.public.dotnet.framework.windowsforms/browse_frm/thread/3aa7167e330c2231

....and, if it's so straight forward and easy, how come you're not over in
the .Net groups answering posts?
It takes code no matter what environment you're in.

Overloads isn't needed in VB... Overrides may've come in handy at times but
I've managed to live without it for quite a long time.

Bottom line is.... I've managed to talk a couple of people here into letting
me experiment with VS2005 once it's released. Performance will be one of the
main factors in our acceptance tests. If the currently released IDE's any
indication of what we can expect performance wise, the entire package will
end up in the recycle bin in short order. Fancy keywords and all.

If we can get "as good" or better, we might actually use it.. If not, we
won't.. Pretty simple really <g>

These threads are funny... regardless of "who's side" someone's on, there
are always losers.... and they go on and on and on. VB (classic... not the
VBish wrapper around C# that's available now) devs have dart boards where
the bulls eye is Anders Hejlsberg's face.

¤ > VB 6.0 supports "interface" inheritance, not native code or
¤ > "implementation" inheritance. You have
¤ > to implement delegation using code instead. Visual Basic.NET has native
¤ > support for both.
¤ >
¤ > What is it that you find to be so difficult with the visual inheritance
¤ > support in WinForms and
¤ > Visual Basic.NET?
¤
¤ Not me.... people that actually try to use it.
¤
¤ Visual Inheritence Sux
¤ http://groups.google.com.my/group/microsoft.public.dotnet.framework.windowsforms/browse_frm/thread/3aa7167e330c2231
¤

Wow, now that's what I call a representative sample of opinions. ;-)

¤ ...and, if it's so straight forward and easy, how come you're not over in
¤ the .Net groups answering posts?

I am, but then you wouldn't know that now would you. ;-)

¤ > ¤ that the VB team could have added the keywords to the language in a few
¤ > ¤ man-weeks of effort"
¤ > ¤
¤ > http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=53587&lngWId=1
¤ >
¤ > Nice rationalization. The problem is that the implementation still
¤ > requires delegation code.  VB 6.0
¤
¤ It takes code no matter what environment you're in.
¤

Huh? You don't have to write delegation code to support implementation inheritance in VB.NET. It's
built in.

¤ Overloads isn't needed in VB... Overrides may've come in handy at times but
¤ I've managed to live without it for quite a long time.

Not the point Ken and you know it. It's just another language tool which supports the OO
implementation and makes code easier to understand. I really couldn't care less if it's your
preference to write additional code to implement such a feature. The fact is that we have a choice -
one which you seem more than happy to deny.

¤
¤ Bottom line is.... I've managed to talk a couple of people here into letting
¤ me experiment with VS2005 once it's released. Performance will be one of the
¤ main factors in our acceptance tests. If the currently released IDE's any
¤ indication of what we can expect performance wise, the entire package will
¤ end up in the recycle bin in short order. Fancy keywords and all.
¤
¤ If we can get "as good" or better, we might actually use it.. If not, we
¤ won't.. Pretty simple really <g>
¤
¤ These threads are funny... regardless of "who's side" someone's on, there
¤ are always losers.... and they go on and on and on. VB (classic... not the
¤ VBish wrapper around C# that's available now) devs have dart boards where
¤ the bulls eye is Anders Hejlsberg's face.

Well I'm only on one side and it's Visual Basic, regardless of version.


Paul
~~~~
Microsoft MVP (Visual Basic)

I've used visual inheritance in C# to quite good effect although once I do I
never use the designer on that object again. As an example, I created a
control called a ButtonBox which was like a combobox with the button in the
rhs without the dropdown array, and a label. The button did nothing except
raise a click event. I inherited this to make a datebox, dir box, color
selector etc. I thought it worked extremely well.

The way they were using it in that thread seemed like a recipe for disaster.
If you've got a base form adding some controls and then adding some more in
a derived form and try to design all of that at once I would expect
problems.

Michael

<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:
Show quoteHide quote"implementation" inheritance. You have
support for both.
support in WinForms and
many do. It doesn't prevent
Show quoteHide quotehttp://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=53587&lngWId=1
requires delegation code.  VB 6.0
could find some way to
Just to be mildly picky -

First, VB6 does provide for "overloading". It can be implemented using
Variants. You might not care for the implementation but it's there. In many
cases, thanks to VB's ETC, you get it without asking. <g>

Second, "Over-rides" is only useful with implementation inheritance. What
would you expect an '0verridden' method in an interface to do?

-ralph

Hey Ralph. Do me a favour. Trim some of the irrelevant stuff from your posts
;-)

Mike

LOL

Often guilty as charged. However, this was perhaps one of my shortest - "to
the point" - replies I have ever posted.

You should have seen the seven paragraphs I deleted. <g>

-ralph

¤ Just to be mildly picky -
¤
¤ First, VB6 does provide for "overloading". It can be implemented using
¤ Variants. You might not care for the implementation but it's there. In many
¤ cases, thanks to VB's ETC, you get it without asking. <g>
¤

You're not being picky, I already admitted that it can be faked, which renders intellisense (amongst
other features) useless for this purpose. ;-)

¤ Second, "Over-rides" is only useful with implementation inheritance. What
¤ would you expect an '0verridden' method in an interface to do?

Well you can fake implementation inheritance through delegates. You mean you can't fake overrides as
well? Or, are you telling me that a faked implementation makes it almost impossible to provide
additional features which support the implementation? ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote renders intellisense (amongst
you can't fake overrides as
impossible to provide
Show quoteHide quote

Show quote Hide quote renders intellisense (amongst
you can't fake overrides as
impossible to provide
[Sorry about the blank. Bad case of 'quick-click-itis' this morning.]

As far as Overrides are concerned I was only commenting that it, as a
compiler instruction, has little value in VB6, or in any language that
doesn't directly support implementation inheritance.

When the smoke clears all an override does is tell the compiler "Hey, call
me not that other guy". Even when when you are 'faking' implementation
inheritance, you are essentially 'overriding' all the 'base' class (object)
methods anyway. Whether you decide to do some extra process, and pass it on
or not, is purely up to the author.

I think we are chewing on the same stick.

-ralph

That's a good question which I think I answered somewhat in another post.
Here's a few more reasons:

Much better interop with com and APIs. This opens up a whole world of
possibilities and is a list on it's own.
Much better oop of course. Again this is a whole list of features.
Strict type casting.
Stricter compiling, eg warning about not returning a value from a function.
Support for wider range of data types, eg variants.
Threading
Windows XP look controls. (I believe you can only partially achieve this in
vb6).
Ability to create services
Web services.
Better tcp/ip support
Native subclassing.
Greater consistancy, eg:
- zero based everywhere
- everything inherits from object and can be assigned to a variable of
object
- every object has ToString method
- All enumerable objects have GetEnumerator method
- all controls and forms inherit from the Control class.
Attributes.
Much more "light weight" objects. Create 1million objects will not be a
problem unlike vb6.
Console apps.
Security, users can decide what they want to allow the app to be able to do.
Ability to add any file to the project, say a word doc and have it there
just as a reference.
Organise source files into directories
Namespaces.
Windows controls created on the fly, much greater control over creating
forms.
Usercontrols work better, none of the hidden wrapper that vb6 has.
Usercontrols don't need to readProperties and WriteProperties events.
Better support for painting.
The "many shades of nothing" (empty, null, nothing, missing) is gone.
2 or more breakpoints on the one line.
XCopy install once the framework in installed.

I could keep going and going. I understand it's not such a difference as
between asp and aspx but it's still a pretty big difference.

Michael

Have you poked around in the interop groups? <g>

I'm not sure how much better dotnet can be at interacting with com
components that VB5/6 is... since they build only com components, they're
pretty good at working with them <g>

Threading _may_ come in handy. I've only needed (actually, wanted) to create
a couple of multi-thread (ax-exe) apps. They worked fine and were
predictable.

Low (real low) priority here. XP is Win2k with a Fisher Price UI. Just
another glittery toy that people eventually get tired of.

Low priority.... I see services as just another way for some hot-shot
developer, thinking they need full control (but don't), to keep their app
running on a users PC. I probably will never create a service... just as the
TSR freaks of the 1980s wanted their TSRs running at all times, the new
Service freaks want the same thing. People have to conciously click on an
icon to run one of my apps <g> They can place them in the startup group if
they see fit. That decision's up to them. Not so with a service.

Below zero priority.

Maybe better "built in" support.

This may come in handy. I've been known to subclass a window here and there
<g> No real problem in VB6 either, once you know how to do it without
crashing.

Dotnet Object = VB Variant

Too bad this is needed. It's ridiculous imo.

Not sure I've ever had a need for that.

All VB classic controls "inherit" from some native windows control so....
same thing. Dotnet may have fewer "design time only" settings.

Far below zero priority. Console = DOS. DOS = dump windows and get some real
performance. If I want a console app, I'll create a batch file.

Not sure I follow you there... our apps usually have 11-13 security levels
the 'process engineer' can set to allow/deny certain functionality.

As a project reference? or just a doc that's attached to the project (for
source control reasons). If it's "just attached", VB6 can do the same with
its related document functionality. File type is irrelavent. Since it's part
of the project, it'll be added to source safe. There's no way to directly
reference these docs in VB6 though.... well.... other than their known
presence.

No prob in VB5/6. Source can be scattered all over the place if you want.

This may come in handy. We'll (eventually) see.

VB5/6s Extender object is a pain. Poking around the dotnet groups, I see
there are many problems with dotnet usercontrols as well. Maybe, once
they're running and working properly, you can benefit from the lack of this
"wrapper" but, until then, you're struggling to just get them to work. In
VB6, creating a usercontrol is just too easy. Especially since VB5/6 ships
with the ActiveX Control Interface Wizard, which is the best wizard I've
seen anywhere (in anything MS sells anyway)

They're there.... they may be hidden... but they're there. If they spit out
XML all over the place, I'll be ticked.

Those shades don't cause a problem once you get to know them

Strange.

Not impressed. Installshield works quite well.

No need.... no interest <g>

Well... thx for taking the time anyway <g> Its rare that I read anything
"real". Most just say "cuz vb6 sux" or "vb classic is a toy"... poking
around the dotnet groups, I can find plenty of code that should be
considered junk. Poking around MSDN or the KB will produce tons of junk code
too (in any programming language you like). I'm not sure who writes this
stuff but I can see how newbies can easily get into some very bad habits
just by taking the advice of the help file they're reading.

That's what I used to think but vb6 only works with a very small select
group of com components, I think the correct term is IDispatch components.
Windows has thousands of com interfaces that are inaccessible to vb6 except
through fairly advanced tricks which generally involve writing helper code
in a language other the vb. This covers a wide range of functionality such
as DirectX, Windows Image Aquisition, all sorts of shell functions etc.

Gotta admit I rarely use it but that's because I don't yet understand it
very well.

Depends on what you do. If you do one off apps then it probably unimportant.
I do apps that go to a few hundred customers so I think it's important to
have it looking as modern as possible. Loading up a win95 looking app on XP
is starting to look a bit dated.

They can turn a service off.

Really? Already my app gets automatic updates (the service downloads them
overnight :-), downloads postcode updates, sends sms and emails all though
the web service. They can report bugs through the web service too complete
with the error log showing the call stack (not sure if this is good feature
yet!).

That's true although it is a fair amount of work, in .net you just type
"override WndProc"

Not quite, vb6 has variant and object. Nothing in vb6 inherits from variant.

ToString is suprisingly handy, say for showing the results from a database
in a grid you just call ToString on everything.

You would use it when you call foreach. VB does has a hidden GetEnum method
which is similar but dot net has it on arrays also (pretty minor I know).

They do, kindof but it's quite a poor implementation. In dot net if you have
a variable of type control you can call standard properties on it such as
left, width, parent etc.

It's not a dos app, it's a win32 console app. It's much like most of the
console apps in windows such the ipconfig.exe program.

Say you've just downloaded an app from the internet but don't trust it, you
can say you don't want that app to be able to access the registry or delete
files or contact the internet. Web page designers can have executables that
the user can choose to run from the website but the program gets very
restricted access to the users pc. I could see it being a problem in the
future having apps in vb6 because they will be considered untrusted and need
special permission to run on the users PC.

Ok, sounds like the same feature, I never used it in vb6.

Doesn't show in the IDE though which is where it really counts. It can
really help to have files in seperate directories. You can even have the
same object names in each directory. As an example, from a recent project I
did I had "ComObjects.IVideoWindow" and "IVideoWindow". The one in the
ComObjects directory was the com interface and the other was my dot net
wrapper for it.

It's good for large projects.

I'm not sure what it is about controls that is hard, I thought they worked
quite well. Some of the features can be a little more difficult because you
need to work out which attribute to apply, eg the DesignerVisible attribute

[DesignerVisible = false]
Public property get WhatEver
End Property

It uses XML for binary properties such as an icon but other properties are
just added as code the form hosting the control.

Better without them tho :-)

It's handy for code like "if x < 0 then x = 0" you can breakpoint on the x =
0  part or the if part.

True, although NSIS is better ;-)

You asked :-)

Michael

LOL.... most users have no idea what a service is, so forget about them
being able to find them in the control panel and turn them off... as a
matter of fact, I've been searching for a site that tells me which services
I can turn off myself to get better performance.... actually, I'd like to
turn all of them off except the ones that are absolutely necessary to run
Windows.

Don't need a web service for Auto Updates. There are plenty of Auto Update
samples on PlanetSourceCode.com, including a couple of "Contest Winners".
Even the call stack/error reporting doesn't require a service. Just an email
client. It's a ton of work to do yourself (once it's done though, it's done)
and wouldn't try to talk someone into doing it. Instead, I'd suggest they
grab VB Watch from aivosto.com. It has this and much, much more (for a
price)

In VB Classic, just show the data. The language assumes that, if you want
someone to see it, and it needs to be displayed in a control, you'll need a
string. No need to call another method.

Dim I As Integer
I = 12
MsgBox I

Can't tell me that a "super duper" language like B# can't figure out on it's
own that, to show that variable in a message box, it has to be a string
representation of that variable.

Simply no interest. <g> Others may like seeing dos windows flashing on and
off... not me. I started using VB, way back when, to avoid console apps
while running Windows. Heck... if I wanted console apps, I'd write Quick
Basic/Assembler apps. Who cares if they're only 16 bit apps... they'd still
stomp all over anything written for Windows, performance wise.

Another way to kill VB. First, release another product called VB, then, make
it harder for people that do use it to deploy it. Finally, introduce service
packs and updates that cause unpredictable behavior so the users/developers
can't trust the results they're getting. Fantastic marketting ploy.

The full path doesn't show? Not sure I'm getting the point here.

Show quoteHide quoteSo.... you're admitting that there's more typing involved in .Net eh? <g>
Everything that VB6 does "behind the scenes", takes code in .Net. One
benefit to that, I guess, would be greater control. One major drawback to
that is.... newbies are going to have an even harder time.

I've seen enough references to the letters "XML" to last me a life time.

I never, ever use single line If/then statements. I haven't since Quick
Basic 4. When I find them in an app, I convert them to blocks.

I've downloaded NSIS at least 10 times now and have never actually installed
it. I'm so used to InstallShield that I naturally grab that when it's time
to create a package. I haven't seen a better dependency scanner that
InstallShield has. No source/projects required.... Just fire up
InstallShield and tell it to keep track of everything your app loads while
it's running, launch the app from within InstallShield, when you're done,
exit the app and return to InstallShield. Everything your app loaded will be
presented in a list you can add to/remove from. Pretty darned easy imo.

No interest in the ASP vs ASPX comparison. There's no contest. Script vs
Compiled. No need to say more.

Have you seen this?

http://www.microsoft.com/windows2000/techinfo/howitworks/management/w2kservices.asp

In 2000 I was absolutely shocked to see all the stuff that was loaded in memory
on my new W2K system. I used the page above to whittle the 30 or so default
loaded services down to just 11 needed services.  But alas, a few re-installs later,
I am just too lazy to go through that list again...

LFS

Yeah. It's crazy. I have a basic standalone home computer running WinXP Home
edition and there are almost a hundred services listed as running in
MSConfig. One day I might trim them down myself.

Mike

Show quote Hide quote Thanks for that... I'll chew on that this weekend <g> I agree... it's nuts.
Way too many things running.

On Fri, 28 Oct 2005 09:44:52 -0700, "Ken Halter"
<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:

Blackviper used to have a good explanation but his site has been in the
rebuild phase for ages, you can see it at
http://web.archive.org/web/20041125015757/www.blackviper.com/WinXP/servicecfg.htm

....also the Elder Geek pages at
http://www.theeldergeek.com/services_guide.htm

Thanks... I'll give those links a try this weekend.

A lot of things are possible in vb6, just a lot easier in .net. For example
the call stack requires all sorts of work to get in vb6 where it's just a
simple call in .net.

It's an advantage that it doesn't figure it out itself. This is one of the
best features of .net. It doesn't allow you to write code such as:

Dim X as Long
X = "Some String"

You're right, I've never used a console app except when testing but it's
still a feature that's there.

The security issue won't just kill vb it will kill any compiled language. I
don't know if it will ever happen but there's a distinct possibility that
extra steps will be required to run unmanaged code.

In vb6 you can have files in directories but that dir tree doesn't show in
the project explorer, every file is still just listed flat under the
project.

Some areas are more difficult and learners probably will have a little more
trouble but that's a trade off for functionality. They have managed to add a
lot more functionality with only a little more complexity.

It's hidden in this case (saving properties for usercontrols)

If it's simple I keep it on the one line, I don't see anything wrong with
"If X < 0 then X = 0"

NSIS really is pretty good. I've always found InstallShield combersome and
they seem to release a new version every six months that you have to pay a
fortune for.

I wasn't offering an asp vs aspx comparison. I was saying I could add to the
list of differences for windows apps.

Michael

I suppose so. But there are some nice things missing, too, that in .net you
have to handle yourself. Autoredraw, for example.

Mike

Autoredraw is quite inefficient and imo should be avoided anyway.

Michael

Show quote Hide quote That depends entirely on what you are doing.

If you are mixing VB graphics and APIs then it is possibly
inefficient, but I think that generally the WM_PAINT messages do a
certain amount of 'look ahead' to avoid duplicate updates.

One can always get round that by using an invisible PictureBox or even
Bitmap
- in Delphi that is called 'Double Buffered'
- I expect that turns up in VB.NET

From what I've seen they just do the exact same paint operation in every
WM_PAINT message.

Michael

Depends what you use it for. Everything is inefficient if you use it in the
wrong way to perform the wrong task! The VB Autoredraw system gives you
extremely easy access to a memory device context into which you can draw
whetever you want using the various API routines. The system won't dump your
drawing to the display until you specifically tell it to do so. What's
inefficient about that?

Mike

It's inefficient because you've got a copy of what's on screen in memory.
Unless what you're drawing is too complicated you may as well just draw it
straight to the screen.

BTW, I think dot net does have double buffer using the SetControlStyle
function.

Michael

Okay. So write me some code to display a dozen or so "transparently drawn"
randomly moving sprites over a background image without having a copy of
your drawing in memory. I'll have another look on the group later tonight to
see what you come up with.

Mike

Ok, here's a very rough example. You need to click the command button to
make the test image transparent and you can move it around with the mouse.
It's hard coded to 15 pixels per twip so you'll probably get odd results if
using large fonts.

http://www.mikesdriveway.com/misc/sprites.zip

Note this is pretty rough and took me a total of 37 minutes, with a little
more work it could be done a lot better. I had to have the command button
because the pixel command didn't work in Form_Load but I'm sure that would
be easy to solve.

Michael

That example has a copy of the background image kept in memory.  Even though
you have not set Autoredraw on the form, VB has created a copy of the image in
memory (eg. the Image property).  That can easily be shown using the following
code:

Private Sub Form_Load()
  Show
  ForeColor = vbWhite
  DrawWidth = 8
  Circle (800, 800), 450
End Sub

There has to be a copy of the form's background image so that it can be re-painted
whenever the user resizes the form.  If you size the form smaller than the image, then
re-size it to larger than the image, the system is able to restore the full image.  Do that
with the above circle showing and it does not redraw the circle because that circle was
not a part of the picture you assigned to the Picture property....

From VB Help on the Image property:

"An Image value exists regardless of the setting for the AutoRedraw property."

With AutoRedraw set to true, you get access to the Image, otherwise you normally
don't.  For an illuminating example, check out the result of this bit of code added
to your original form, and see how it responds:

Private Sub Form_Load()
  ForeColor = vbWhite
  DrawWidth = 8
  AutoRedraw = True
  Circle (800, 800), 450
  AutoRedraw = False
  SavePicture Me.Picture, "D:\temp\Form1Picture.bmp"  ' ~ 48K
  SavePicture Me.Image, "D:\temp\Form1Image.bmp"    ' ~ 2.3 M
End Sub


LFS

Yes it's got a copy in memory but the point is it has *one* copy.

This I know.

With autoredraw set to true you'd have 2 copies of the bitmap in memory plus
any extra space on the form wasting memor. This would defeat the purpose of
what I was trying to do in the first place. Although I wouldn't have
normally put the bitmap into the picture property.

Michael

Well, the challenge was to use no copies....

How would you demonstrate that?  As I pointed out, VB's own help files say
there is an Image value to the form no matter what the AutoRedraw setting.  We
agree there, but no where have I found where it says you get a second copy when
AutoRedraw is set to True.  As I indicated, only when you set AutoRedraw to True
can you actually write to that Image bitmap.  It is there with or without AutoRedraw
set, so how is using AutoRedraw inefficient?  Set one way you access the screen, and
set another you access the persistant graphic, both are present regaurdless of what
the setting is...  I'd have to see proof of your '2nd' copy' before I go along with that....

Can you demonstrate there is a 2nd copy?

LFS

You can't use no copies, you have to have it somewhere. :-)

But it would be nothing.

Show quoteHide quoteI really should have said additional copy. You can test this by loading a
form with autoredraw set to true and watching how much memory it uses.

Michael

Not so, it is still present as my earlier post showed:

Private Sub Command1_Click()
  Picture1.BackColor = vbBlack
  Picture1.Circle (400, 400), 300, vbWhite
  Me.Picture = Picture1.Image
End Sub

If the Image property is Nothing, then what gets assigned to the form?

It uses the same amount as a form without AutoRedraw set.

We may be seeing a difference in versions here, if you actually get Nothing
for the Image property in the example above.  In VB5 the TypeName returned
for the Image property (with AutoRedraw unchanged (false)) is "Picture".

If it was actually Nothing then the form should not be affected, but in my case
it gets the black background, as indicated in my earlier post....

LFS

On Sun, 30 Oct 2005 01:13:31 -0500, "Larry Serflaten"
<serfla***@usinternet.com> wrote:

Show quoteHide quoteIn VB5 resizing the Form down loses bits of the circle
- minimizing, then maximizing loses the lot
- passing another Form over a bit of it also 'erases' bits
- moving/dragging the Form retains the circle, provided it is not
dragged out of view

I don't think that it is the Image property at work, I think that
Windows is 'reading' the screen buffer (or more likely a single copy
of the current screen buffer).

(seems there a problems tonight..  this is the third attempt, the others were
reported as being rejected...)

Show quoteHide quoteIf the system is not using a second image other than the screen buffer,
then why does the background image remain when the circle gets erased.
Where is that image data (without the circle) coming from?  It is the Image
data, did you see the two .bmp files from the last example?

LFS

Yeah. That's reasonable code if you just want to move a single transparent
sprite manually, but it is *hugely inefficient* and since this "subthread"
was kicked of by you telling me that Autoredraw was inefficient then it
doesn't really help your point. At first sight it looks as though you don't
have to do a lot to move the "sprite" (just change its Left and Top
properties in your MouseMove event), but of course it isn't really like that
in practice. You have to take into account the massive overhead of creating
regions in memory and of forcing the operating system to deal with your
region every  time it needs to move the picture box.



To demonstrate what I mean by the huge inefficiency of your method, I
changed your code slightly so that it creates a user defined number of
similar picture boxes and animates them as sprites (in exactly the way that
you are doing, except it moves them under the control of a timer). If you
remember, my original request was for you to write a program that animated a
dozen or so sprites. I set the animation period to about 15 milliseconds to
give me approximately 66 Hz animation rate and moved the sprites randomly
around the screen, with each one moving exactly one pixel at a time. I am
using a reasonably powerful 3000+ AMD processor with Radeon 9800 graphics
card and the largest number of "sprites" I could animate before the
animation rate dropped below 66 Hz was seven! That's not a lot of sprites,
and it certainly doesn't leave much time for anything else to happen. By the
time I got to a dozen sprites they were moving at only half the desired
speed, at a rate of less than 30 Hz. By the time I got to 35 sprites the
animation rate had dropped to a dreadful one frame per second! Contrast that
to the *seven hundred* or so similarly sized sprites that I can animate at
the full 66 Hz on exactly the same machine using a VB Autoredraw picture box
and you'll see how inefficient your program really is. That's a hundred
times as many sprites as your code can animate at 66 Hz!!! Before my
"Autoredraw picture box" code gets down to one frame per second (which yours
hit at just 35 sprites) I have to be animating more than sixty thousand of
the little buggers using my own code! Your own program would effectively
lock up completely at less than one thousandth of that number of sprites!



Just for a laugh I tried setting your own code to animate 700 sprites
(something which my own code would do with no problems at all at the full
desired 66 Hz animation frame rate). I should have realised it was a "non
runner" when my computer became unresponsive even before I clicked the
button to start the animation! Anyway, on clicking the button my WinXP
machine effectively locked up completely! I did eventually persuade the task
manager to appear (after trying many times) and every single task was shown
as not responding, including the task manager itself! When I finally managed
to get my computer to attempt to turn itself off I was shown loads of
different "not responding" dialogues (at a very slow rate!) and then
eventually, after about ten minutes or so, the machine seemed to give up the
ghost altogether and nothing was happenning. In the end I had "pull the
plug"!



Don't get me wrong, I'm not knocking you in any way. It's just that you
seemed to "jump at me" a little bit when I mentioned VB6 Autoredraw picture
boxes in an earlier message and you seemed to denigrate my use of them by
telling me that Autoredraw was inefficient. I'm merely telling you that,
used properly, the VB Autoredraw system can be very efficient indeed. I
thing you have to agree with is that the ability to animate 700 sprites at a
full 66 Hz animation rate (using the API to draw into a VB Autoredraw
picture box) is a little better than the ability to animate 7 sprites using
your own method!



Mike

.. . . sorry. My last post seems to have grown extra large paragraph
spacings. Here it is again, just in case you think you've reach the end of
the message at the first paragraph . . .

Yeah. That's reasonable code if you just want to move a single transparent
sprite manually, but it is *hugely inefficient* and since this "subthread"
was kicked of by you telling me that Autoredraw was inefficient then it
doesn't really help your point. At first sight it looks as though you don't
have to do a lot to move the "sprite" (just change its Left and Top
properties in your MouseMove event), but of course it isn't really like that
in practice. You have to take into account the massive overhead of creating
regions in memory and of forcing the operating system to deal with your
region every  time it needs to move the picture box.

To demonstrate what I mean by the huge inefficiency of your method, I
changed your code slightly so that it creates a user defined number of
similar picture boxes and animates them as sprites (in exactly the way that
you are doing, except it moves them under the control of a timer). If you
remember, my original request was for you to write a program that animated a
dozen or so sprites. I set the animation period to about 15 milliseconds to
give me approximately 66 Hz animation rate and moved the sprites randomly
around the screen, with each one moving exactly one pixel at a time. I am
using a reasonably powerful 3000+ AMD processor with Radeon 9800 graphics
card and the largest number of "sprites" I could animate before the
animation rate dropped below 66 Hz was seven! That's not a lot of sprites,
and it certainly doesn't leave much time for anything else to happen. By the
time I got to a dozen sprites they were moving at only half the desired
speed, at a rate of less than 30 Hz. By the time I got to 35 sprites the
animation rate had dropped to a dreadful one frame per second! Contrast that
to the *seven hundred* or so similarly sized sprites that I can animate at
the full 66 Hz on exactly the same machine using a VB Autoredraw picture box
and you'll see how inefficient your program really is. That's a hundred
times as many sprites as your code can animate at 66 Hz!!! Before my
"Autoredraw picture box" code gets down to one frame per second (which yours
hit at just 35 sprites) I have to be animating more than sixty thousand of
the little buggers using my own code! Your own program would effectively
lock up completely at less than one thousandth of that number of sprites!

Just for a laugh I tried setting your own code to animate 700 sprites
(something which my own code would do with no problems at all at the full
desired 66 Hz animation frame rate). I should have realised it was a "non
runner" when my computer became unresponsive even before I clicked the
button to start the animation! Anyway, on clicking the button my WinXP
machine effectively locked up completely! I did eventually persuade the task
manager to appear (after trying many times) and every single task was shown
as not responding, including the task manager itself! When I finally managed
to get my computer to attempt to turn itself off I was shown loads of
different "not responding" dialogues (at a very slow rate!) and then
eventually, after about ten minutes or so, the machine seemed to give up the
ghost altogether and nothing was happenning. In the end I had "pull the
plug"!

Don't get me wrong, I'm not knocking you in any way. It's just that you
seemed to "jump at me" a little bit when I mentioned VB6 Autoredraw picture
boxes in an earlier message and you seemed to denigrate my use of them by
telling me that Autoredraw was inefficient. I'm merely telling you that,
used properly, the VB Autoredraw system can be very efficient indeed. I
thing you have to agree with is that the ability to animate 700 sprites at a
full 66 Hz animation rate (using the API to draw into a VB Autoredraw
picture box) is a little better than the ability to animate 7 sprites using
your own method!

Mike

As I said it was a rough example to prove it was possible, there are many
ways to do things. I wrote this code in a little over a half hour never
having done anything similar before (I've done lots of userdrawing before
but always windowsy stuff). This code is probably highly inefficient because
it creates the regions pixel by pixel. To use this quick hack as some sort
of comparison to code you've spent hours optimising is a little silly.

That being said, in this sort of case I probably would use double buffering,
which is why I said in my previous post "Unless what you're drawing is too
complicated you may as well just draw it straight to the screen."

Getting back to the original point that dot net doesn't support autoredraw,
it actually has far superior support. You can create in memory bitmaps of
any size and draw them in the WM_PAINT message. You can create these bitmaps
of any number and size or create them just for painting and destroy them
immediately. Much better than just flicking on the autoredraw property that
uses large amounts of memory. It might work well for one app but imagine if
every programmer used it. :-)

Michael

How about attempting to do some simple drawing functions, like a rubberband
box?  Have you compared the code?  (Try to emulate the demo below....)

Would you care to demonstrate how making a new bitmap the size of a picture
box in every paint event is going to use LESS memory than a single image held
in memory?  You don't even get control over the destruction of those bitmaps
and have to rely on the garbage collector to destroy them at some later time.
It seems to me that would use far more memory.  10 or 15 bitmaps (or more)
waiting to be cleaned up, compared to one persistant bitmap.  It seems a
no-brainer to me which uses the more memory....

Can you write some 'far superior' VB.Net code to do something as simple as
a rubberband box?  For an example, this has always been easy to do in VB:

LFS

Option Explicit
Private MX As Long, MY As Long
Private OX As Long, OY As Long

Private Sub Form_Load()
  Move Left, Top, 6300, 6600
End Sub

Private Sub Form_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
  MX = X
  MY = Y
  OX = X
  OY = Y
  DrawWidth = 5
  DrawMode = vbXorPen
End Sub

Private Sub Form_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
  If Button = vbLeftButton Then
    Line (MX, MY)-(OX, OY), vbWhite, B
    OX = X
    OY = Y
    Line (MX, MY)-(OX, OY), vbWhite, B
  End If
End Sub

Private Sub Form_MouseUp(Button As Integer, Shift As Integer, X As Single, Y As Single)
  Line (MX, MY)-(OX, OY), vbWhite, B
  DrawMode = vbCopyPen
  Line (MX, MY)-(X, Y), vbBlack, B
End Sub

Private Sub Form_Paint()
Dim sz As Long
  DrawWidth = 3
  DrawMode = vbCopyPen
  Line (30, 30)-Step(6000, 6000), vbWhite, B
  DrawWidth = 30
  For sz = 40 To 2100 Step 900
    Circle (3000, 3000), sz, vbWhite
    Circle (3000, 3000), sz + 450, vbRed
  Next
End Sub

Very easy but to be honest I couldn't be bothered. This is just simple
drawing commands so I don't see why it wouldn't be easy.

That's not correct, you can call Bitmap.Dispose to remove it from memory
immegiately.

Having the bitmap in memory for a short period of time is much better than
having it there permanently.

The line command and circle command are just calling the windows API
functions. Dot net has much greater support for the the basic windows
drawing functions natively. For example you can create brush and pen objects
natively.

Michael

So. What's your point? You can have a bitmap in memory for as long or as
short a time as you want using VB6. And keeping a bitmap in memory for the
period of time you are actually using it is essential whatever language you
are using. You can hardly delete a bitmap that you are actually using! It
just would not make sense, and it would prevent your program from working!
Just what point are you trying to make here? If you are saying that you
should *always* delete a bitmap as soon as you have used it then that
implies you will need to create it and  initialise it and fill it with its
bitmap data again the next time you wish to use it. If such a bitmap
(containing a picture for example) is being used repeatedly at a rate of
perhaps 60 "uses per second" then it makes sense to keep it in memory
permanently, or at least until you cease to use it at such a rate. If it is
not in memory then where are you going to keep it? On a disk! Then load it
from disk again a sixtieth of a second later! Behave yourself! The mind
boggles!

Mike

Show quote Hide quote Chill out mike. All I'm saying is that it is possible to destroy the bitmap
in dot net. It was just one advantage. You can't do that with autoredraw,
unless you turn the property on and off? :-)

Michael