Why VB 6.0??

Quote:

---

Originally Posted by TheCPUWizard

Gremmy, You have just hit on something I would have NEVER considered.

"Upgraded" applications will definately perform poorly compared to their originals in most circumstances.

This is akin to taking a "C" program and making it compile under a "C++" compiler, and then calling it a good Object Oriented Program. :sick: :thumbd:

Code needs to be architected for the target environment from the ground up. The structure of a .NET program is radically different than a VB6.0 program (or a native C++ program).

This is akin to constructing a building you using one technology (eg. Steel), but following the contruction methods of another technology (e.g. Wood).

---

I know exactly what your saying there.. however because 90% of the project was maths and logic's, i figured that the upgrade method was the fastest way to get that all in, there after i removed the graphics and went the .NET way ...

The logic and maths works almost exactly the same. the graphics however work almost completely differently. when testing, trying it the 'old way' i almost killed the proccessor because i was unaware that every "drawline", forces the picturebox to do a refresh. the proccessor usage went to 100% in no time. however with the better .NET method, and buffering, i reduced it to less that 10%, peek..

The next part is to do a time comparison between the two versions.

I'll see about doing that this week end.

Quote:

---

Originally Posted by GremlinSa

The logic and maths works almost exactly the same. the graphics however work almost completely differently. when testing, trying it the 'old way' i almost killed the proccessor because i was unaware that every "drawline", forces the picturebox to do a refresh. the proccessor usage went to 100% in no time. however with the better .NET method, and buffering, i reduced it to less that 10%, peek..

---

Sounds to me you didn't enable the autodraw on the picturebox. When your done making your lines you use the picturebox.refresh. See you invoked it. It is no longer just the old way that is slow. It is the old way that is the right way that it works fast. If that isn't fast enough, use the window's api for creating a line. If that isn't fast enough, use opengl. If that isn't fast enough, your code is just plain coded wrong ;(

Quote:

---

Originally Posted by Joeman

Sounds to me you didn't enable the autodraw on the picturebox. When your done making your lines you use the picturebox.refresh. See you invoked it. It is no longer just the old way that is slow. It is the old way that is the right way that it works fast. If that isn't fast enough, use the window's api for creating a line. If that isn't fast enough, use opengl. If that isn't fast enough, your code is just plain coded wrong ;(

---

Have you done graphic work in .NET..

the picturebox control no longer has a autodraw feature...

How ever the method you described, is exactly the method used in the VB6 version...

Also in .net you do not draw directly to the picturebox object, you create a graphics object of the image / bitmap you want to draw onto, and use this object to do the drawing on ...

Gremmy..

Quote:

---

Originally Posted by GremlinSA

Also in .net you do not draw directly to the picturebox object, you create a graphics object of the image / bitmap you want to draw onto, and use this object to do the drawing on ...

Gremmy..

---

Sounds like a buffer, which is what I always do anyway, via API.

Once created, there's also the DoubleBuffered option, that you can enable and use. This creates two graphics objects for you to use.

Despite the fact I've only just finished my A-Levels, I started learning programming around the same time VB6 was released, and I've been working with it happily for a good section of that time. I do subscribe to the mentality of "If it ain't broken, don't fix it" (which is why the second app I ever wrote is still running on all of my machines).
However, I'm off to study Information Systems Engineering in October, and I will be bitterly disappointed if they don't teach VB.net. Despite the fact that it has had it's issues (and the .Net framework refuses to update properly on this machine), it is at some point going to be the future.

I just wish Visual Studio wasn't so **** big. Or that I had a faster internet connection :D

I have to admit, vb.net is a LOT faster than vb6 was. I've now wired up my panel demo to a sql server express file. As fast as I can click the drop-down(s) producing 41x14 different panels. they each get drawn independently with 4 to 144 different blocks.

the old program used to draw one block on the screen at a time (using Line() statements). it would take a few seconds to draw one small panel, and about 10 seconds for the largest one.

this will be easy to upload the detached dbo to my site, and use sql server.

edit: running locally courtesy of Camtasia www.siokonline.com/blocks

Quote:

---

Originally Posted by javajawa

I just wish Visual Studio wasn't so **** big. Or that I had a faster internet connection :D

---

Lol ..

The main reason it is so big, it contains all the languages in one ..

Compare the .NET install to having a system with all the following installed.
VB4 , VB5, VB6 (.NET 2008 has framework 2.0, 2.5 & 3.0. so it needs to be comparable)
Borland C.
VC5, VC6.
Java.
ASP.

(Hmm Did i miss any ??)

And then try running the IDE of all of them at the same time ... I dont think that any system will be able to provide enough resorces to handle all of them .. Expecially if trying to debug a app that has components written in each lang......

Unfortunatly i had the grandkids over for the weekend, so access to the VB6 system was a little limeted, and i was unable to complete the testing ...

But i will complete it soon...

Dglienna said

Quote:

---

I have to admit, vb.net is a LOT faster than vb6 was

---

As a developer we try out various bits of software, and even write our own

Typically you write some code then test to see if it works - you dont normally sit down and hammer a program you have just written for a long time.

Consequently, the experience as a developer is this (I use VB.Net)

1) Load up the program into the IDE - this typically seems to take forever

2) Click on a form / module whatever - this takes forever to load

3) Do some changes to the code, then attempt to run the application - Dot net goes into constipation mode while it tries to sort out the exe to be run

4) Finally the application comes up

5) You attempt to run something (that hasn't been run before) Dot net again excuses itself while it "just in time compiles it" then finally the program runs

6) Unless you are doing some fancy code, possibly with multi threading, there is no way it appears any quicker than its VB6 equivalent. I work with Accounting systems which really dont have much room for multi-threading applications.

THATS MY EXPERIENCE AS A DEVELOPER - Its really not much fun - Certainly not a pleasure to work with

BUT .........


Dglienna said

Quote:

---

I have to admit, vb.net is a LOT faster than vb6 was

---

So where are the speed increases (apart from multi-threading applications)

EVERY DOT NET APPLICATION I HAVE HAD EXPERIENCE WITH is criticised for its bad user experience - its just so slow

Is this the fault of Dot Net or is this the fault of developers who dont know how to write FAST Dot Net Applications ?

PS: One of the most criticised is Microsoft 2008 Accounting EXpress which I presume was written by Microsoft Programmers (go to their users forum if you want an ear full)

So ............. who then knows how to write efficient Dot Net Apps ?

And ... who is going to teach us the right way to do it ?

(Good Dot Net examples are few and far between)

Quote:

---

Originally Posted by dglienna

the old program used to draw one block on the screen at a time (using Line() statements). it would take a few seconds to draw one small panel, and about 10 seconds for the largest one.

---

Well, of course the Line statement is going to be slow! Try it with win32 API calls.

I think I'll post a little drawing function, but it will be up to someone else to write the .net "equivalent". Should be interesting to compare VB6 speed using win32 API to .net graphics objects, and also to .net win32 API calls.

There will be differences between a well written program and a poorly written one for any language. So before one can say well written .net code is faster than VB6, one needs to be sure the VB6 code is also well written.

George111,

Yes VS-2005/8 takes a good amount of time to load. But typically it should only be loaded once or twice per day.

Also, it is an environment designed for "significant" projects. I just finished a job where the main solution consisted fo 61 projects and over 8000 C# source file [120MB]. Visual Studio handled this without a problem and was perfectly responsive. For example a typical build (NOT re-build) took about 20-35 seconds.

If you put together a "spec sheet" on the machine you are running, and can also capture some PerfMon logs of VS performing activities such as opening forms, making changes, etc. I would be glad to look at them (PM or e-Mail me).

A large part of my professional life is training people to write good .NET applications. (In fact Microsoft convinced me to mothball my consulting firm for almost 2 years while I worked as a Sr. AppDev Field Consultant for them in 2005-2006). I am hoping to publically post a good part of my training material soon (I was gathering it for a book deal which now looks like it is not going to materialize).

Edited: Point #4 had a blooper....

Quote:

---

Originally Posted by WizBang

There will be differences between a well written program and a poorly written one for any language. So before one can say well written .net code is faster than VB6, one needs to be sure the VB6 code is also well written.

---

Agreed. And I would expect the following (assuming both contestants are experts in the respective environment and can write 99.9% the "best" program possible.

#1) If both contestants are constrainted to use JUST the environment (No "extern" for VB6.0, No "PInvoke" for .NET) then the .NET code will be faster.

#2) If both can use ANY available means, then the results should be visually indistinguihable (ie a person with a manual stopwatch on a sequence taking at least 30 seconds, should not be able to consistantly measure one as being faster then the other).

#3) If the program is designed to run on a multi-core machine (ALL programs these days should be), then the .NET implementation will make much better use of the available processing power.


#4) Regardless of the above, the .NET developer will have a working program before the VB.NET VB 6.0 developer. This would be event greater if the code has to be jointly developed by a 2-3 person team.

To "really" do this challenge, it would be great to get a set of teams together at a "convention" (off-site) and dedicate a (long) evening. A challenge like this probably could get sponsored....

Quote:

---

Originally Posted by GremlinSA

Lol ..

The main reason it is so big, it contains all the languages in one ..

And then try running the IDE of all of them at the same time ... I don't think that any system will be able to provide enough resources to handle all of them .. Especially if trying to debug a app that has components written in each lang......

---

Well, as it stands, my Dell can barely run Media Player and VC2008 at the same time. But it is on the brink...(has anyone got a computer they don't want? Or even some parts? PLEASE!?)

In fact, I must say most of what I'm finding after downloading 3.4Gb of software (and then installing all of about 0.8Gb or it...*sigh*) has been summed up by George1111.

However, I'm already finding huge benefits from the way the whole thing works - so I'm happy...But I'll still be interested to know which one works out faster, if you do finish those tests.

Quote:

---

Originally Posted by TheCPUWizard

Also, it is an environment designed for "significant" projects.

---

Quote:

---

Originally Posted by TheCPUWizard

If the program is designed to run on a multi-core machine (ALL programs these days should be)

---

Am I the only person who misses the time when people wrote programs to be as small and simple as possible? Or is it because I'm the only person in the world who still owns two computers which can only run win98?

Quote:

---

Originally Posted by javajawa

Am I the only person who misses the time when people wrote programs to be as small and simple as possible? Or is it because I'm the only person in the world who still owns two computers which can only run win98?

---

The more I do the coding gig, the more I am interested in reducing the time it takes to develop. As such I spend quite a bit of time undestanding and leveraging the latest technologies.

Of course I expect reasonable performance, but 'fastest and uses the least amount of resources' really doesn't place that high on the list of priorities. I place a higher premium on how do different components interact with each other and how easily I can get the components to work together.

It seems the more experience I get, the more I leverage the features of the framework I'm working in.

Transitioning to newer framework doesn't come for free either. I've spent quite a bit of time learning new technologies throughout my career. I did this when I coded in C++ (because I took the time to learn MFC, ATL, STL, SQL and so on) and I do this now in .Net by learning the latest .Net3.0/3.5 features (WPF, WCF, and WF). I suppose I am paranoid about becoming obsolete, but I must say that every technology that I've spent time learning has so far paid off with either a simpler way of doing something, a reduction of development time or both.

It's easy to sit there and say that the newer technologies are slower - it's harder to go out there and learn the new stuff to find out if it is actually slower and if so whether the speed difference is significant.

Btw, there is a similar thread in the general forum (What languages to use) that has some performance tests between C++ and C#. The results may surprise you (and I expect the performance of VB.Net to be on par with C#).

Quote:

---

Originally Posted by javajawa

Am I the only person who misses the time when people wrote programs to be as small and simple as possible? Or is it because I'm the only person in the world who still owns two computers which can only run win98?

---

If you have been reading my posts you know I have be at this since 1972, and also that I own a (lamost) restored 1968 DEC PDP-8. The equipement I own cost over $150K when purchased new.

Size and Speed have always been about cost (and I have posted on this at length). If you have a professional developer making $25K / yr (very good money in the early 1970's), and a 4K memory upgrade costs $15K. Then investing a few months of work to save $15K (per machine!) is a no brainer.

But look at today. A top notch developer (New York City, USA) can command a salary of $150K-$225K easily. And a 4GB memory stick costs under $100.

Using these figures, in 1972 byte of saved memory ($2.44) was worth. about 12 minutes of development time. Today, that same byte of memory is worth 3.32 microseconds of development time.

I dont know about you, but in the oldr programs, I could usually find 5 bytes in an hour of examination of a normally written program within and hour. But I dont think there is anyone who can do anything in 3.32 microseconds....