Printable View
The bottom line is use a newer framework if you find some benefit to it.
If you think the old way is better, stick to it.
That being said, how about a couple of questions...
Do you have problems currently finding VB6 work?
How long more do you all think VB6 will be in demand?
I don't have any problem getting work in VB though most of my current projects use a mixture of VB and dot net and will likely be going more toward dot net as time marches on.
I think VB6 is a fine langauge for many projects and will continue to be as long as it can run on the current OS and hardware being used.
Lately I have been writing quite a few apps for mobile devices in Dot Net. It works fine but there has been need for quite a few lines of code to do the work here. After writing many apps I decided to dive into the designer source files in one of my projects and see if I could speed it up a bit.
I ended up writing a program in VB6 that actually writes a good bit of the dot net code for me based on the controls that have been added to the designer. In general I would say this little VB utility saves me any where from 1-4 hours per project by inserting code for common tasks based on control names.
WillAtWell,
VB6.0 was probably the "best" language when it came out. But you say you are still developing commercial applications in it. Given that it is out of support, what would your customers (how hopefully have paid you LOTS of money) do if all of your products just stopped working the next time they did a "Windows Update", and there was no way to make them work again...
I doubt they would be happy.
Granted this is very slim possibility, but "officially" it can happen. And some recent updates HAVE broken aspects of VB6.0 with the official answer being "sorry, that is no longer supported...change your application".
To me providing commercial applications on a platform that is no longer supported is bad business.
As to the comparisions, it seems I am having trouble getting my point across. If I was a programmer who had never seen windows or any language that can be used to program windows and I read JUST the VB 6.0 documentation, there are certain things I can do. To go beyond this I have to learn "more" than just VB6.0.
On the other hand, if I read all of the .NET documentation, then I can do many more things using just .NET provided information.
This is the difference between:
VB6.0 (only) vs. .NET (only)
and
VB6.0 (plust other things you can use) vs. .NET (also plus other things).
If you choose the latter (which IS the real-world case for development), then you are NOT comparing VB6.0 to .NET...you are doing something different.
THe very initial draft of my performance comparisions are discussed @
http://www.codeguru.com/forum/showth...93#post1739193
I guess the point I was trying to make is that the Dot Net framework is not the dot net language. It is an API that works with the dot net languages. Just because it has the same dot net in the name does not mean it is part of any of the languages.
As for the language being supported by MS. I have never had any support issue rasied with MS on any program I have written supported or not. If a customer installs software on thier machine that causes something I wrote to stop working then they will be calling me for support and we will work through it.
It is very possible that I will begin to get support calls on Vista machines soon but it really does not matter if MS supports VB or not. The customer is going to look to me for the solution and I will provide it.
Believe it or not I may even write an occasional VBDos program or heaven forbid an old dos style batch file.
More than an API, but I agree with you. It is the ENTIRE package that makes it compelling (at least for some).Quote:
Originally Posted by WillAtwell
Different business models work for diferent people/companies, and if this works for you, then that is great. You are well aware of the issues involved.Quote:
As for the language being supported by MS. I have never had any support issue rasied with MS on any program I have written supported or not. If a customer installs software on thier machine that causes something I wrote to stop working then they will be calling me for support and we will work through it.
It is very possible that I will begin to get support calls on Vista machines soon but it really does not matter if MS supports VB or not. The customer is going to look to me for the solution and I will provide it.
Believe it or not I may even write an occasional VBDos program or heaven forbid an old dos style batch file.
For my company, it does NOT work. I simply can not afford to have a client's machine crash and cause over $1 million in lost revenue (this actually happened to me in 2002 - fortunately the source of the problem was NOT related to anything my firm did). Nor can I afford to have 3,000 field service engineers all calling me because of problems. The customer(s) will contact my firm, but I NEED the ability to get full support from Microsoft (or any other Vendor that I use) including having their personell willing and able to travel to a customers site (and getting paid well for it!).
My real concern (and the original reason I started this thread), is that I am convinced that the (vast?) majority of people are NOT aware of the "trade-offs" or are making their decisions on incomplete or even downright WRONG information.
The sample applies for people who are learning C++ based on VC++ 6.0. The information they learn is not ISO standard compliant and when they go to get a job it causes problems.
While ramping one of my current clients up earlier this year, I interviewed about 20 candidates for 5 job openings. Most of the positions were at the entry (to low-middle) level. About 25% of the candidates were eliminated specifically because they only had used VC++ 6.0, and had learned poor habits. The overhead of re-training them was sufficient to make other candidates who had a good working knowledge of the standard (e.g. STL TR1) much more desirable.
My heart went out to them, they spent 2-4 years of their life learning something, only to find that it was not a marketable skill....
BTW Last I checked it was possible to undo an update. I think the notion of suddenly being unable to make it work is very very far fetched to say the least. Even my old vb3 apps still work.
Almost all of the automatic (high priority) ones CAN. But a few can not. Also many Service PAcks can NOT.Quote:
Originally Posted by WillAtwell
(emphasis added)
Agreed. But there are cases where (usually minor) changes are required (look ad dglienna's recent issues with CAPICOM!). This can still be a hassle, or worse.Quote:
I think the notion of suddenly being unable to make it work is very very far fetched to say the least.
99.99% of them will. But I know that VB4.0 fails the full set of QA tests on any XP machine with SP2 installed. The failures are "fringe cases" that are unlikely to impact the vast vast majority of programs, but technically is does not "work" and there were no plans to make any changes to that situation..Quote:
Even my old vb3 apps still work.
There is also a useful practice known as backing up ones system that proves to be quite handy from time to time. The point is that there is always a solution when proper steps are taken and if a company has an operation that could loose millions from a short time offline then they would be a fool not to have redunant systems and fully test any and all updates before installing them on a live system. Not to mention daily backups at the very least.Quote:
Originally Posted by TheCPUWizard
These minor issues can pop in with a supported language as well.Quote:
Agreed. But there are cases where (usually minor) changes are required (look ad dglienna's recent issues with CAPICOM!). This can still be a hassle, or worse.
Yep.. but then again those apps were not written for XP, most were not even written for Win NT yet most of them still work.Quote:
99.99% of them will. But I know that VB4.0 fails the full set of QA tests on any XP machine with SP2 installed. The failures are "fringe cases" that are unlikely to impact the vast vast majority of programs, but technically is does not "work" and there were no plans to make any changes to that situation..
On the other hand I developed several apps in dot net for Windows CE devices only to find that none of them work at all on the new version of CE. I had to purchase and install VS 2005 on a seperate computer, convert my apps, change several lines of code then learn the new build procedures just to get a simple app to work on the new OS. I also am forced to maintain the 2003 source and a full environment for it to support the CE 4.x apps which are still in the field.
So far this is the only major issue I have had with dot net but it is one that I have never had with prior versions of VS.
Imagine manager with a POS system that hides his fuctions from employees, that he can't log into anymore. He types any password, and the system crashes with an error. Don't know when they tried it before, though.
Except, the same thing happened to ME in the vb6 ide! Nobody ever heard of the problem, and it is not being supported.
If the employees wanted to break the system, they can, now. I had to support a product that I had quit updating, because of one client...
Here's one small issue with VB6 that i've personally cime across..
A Application that I developed and compiled on a WIN 98 system, failed to run on a XP system. (No API's, No external Dll's, Only a Access DB) However the same executable ran fine on a Win 2000 system..
I re-compiled it on a Win 2000 system (No alterations to the code), and it ran perfectly this time on the XP system (and on Win98)...
What this told me is that backwards compatibility is not guaranteed right back to ver 1..
Sure, almost 50 % of the methods originaly conceived for Windows Ver 1 (earliest windows i got was 3.0) May well still be in the mix, however with each version, they would have evolved to take advantage of the easier/better/faster capabilities of the newer proccessor's. Many simply fall away as they are no longer needed. (How many proc's have full support for 8bit assembly ??)
And soon 16bit will fall to the side too.. (if not already.)
There have been cases when a OS or system has a flaw or bug. Developers wrote there aplications to either get around this flaw, and even take advantage of it..
This biggest Flaw that was taken advantage of (in my opinion) was that of the SID chip on the Commodore 64. (the Audio chip) It has a small but critical flaw, under specific conditions (100% reproducable) the audio output was held High. However Final volume settings could alter this level. Not too long after this 'BUG' was discovered, many Game developers used this method to play a digitised voice.
when the later 'Better' C64 came out, this 'bug' was fixed and the digitised sound no longer worked, (Actually all you got now was a soft scratching sound)
This Flawed chip today is in high demand because is was heralded as a big step in sound technology. (BTW, the Chip designer later developed the sound Blaster cards for PC's)..
Back to topic...
Eventually backwards compatibility is lost, With MS now no longer supporting VB6, they will not make any effort to support it's runtimes in the OS, and no amount of tinkering on your side will enable it to run, as the DLL's, methods, and Functions used in the Runtimes will either not exsist or be altered in some small way that renders it useless to the runtime.
When this happens, All VB6 developers that did not at least learn .NET or other language, will be out of a job.
I agree that it will become unusable at some point but not in the very near future. It look slike at least for the time being Vista supports it and we know XP does.
I also have had at least one project that did not run properly under XP until I recompiled it on an XP machine. To me that is no big deal and the project still worked on win 98, NT, 2k after the recompile. In fact it was actually faster under win2k than it was before.
I didn't use any GDI with this, I simply did:Quote:
Originally Posted by WizBang
And it was tremendously quick. Example Attached. With cases such as these, there is no need for API, as .NET already provides that functionality :)Code:Private Sub Form1_MouseClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Me.MouseClick
Me.BackgroundImageLayout = ImageLayout.Tile
Me.BackgroundImage = PictureBox1.Image
End Sub
Have a little respect won't you ¿ Read this again:Quote:
Originally Posted by Joeman
http://www.codeguru.com/forum/showpo...&postcount=186
OK, then how about VC++ without any APIs :confused:Quote:
Originally Posted by TheCPUWizard
Don't understand the logic of that statement :)
http://forums.codeguru.com/images/ie.../2007/02/1.gif http://forums.codeguru.com/images/ie.../2007/02/1.gif http://forums.codeguru.com/images/ie.../2007/02/1.gifQuote:
Originally Posted by HanneSThEGreaT
Very nice Hannes, and you gave us a completely different side to this. there are hundreds of different ways to complete the same task. Each with different advantages, and disadvantages..
Your code thake this quest to a new level, you took the task and gave us a very literal solution. however i'm not sure how comparable this code is to the VB6 API one is..
Yes the set task is done, however your method drop's all the graphics work to the OS, and like CPUwizard said here "If you are going to have the work done by things that are not directly native to the language, then the tests become meaningless"
However I do applaud you for it, as it proves one more point, .NET incorperates a lot more of the OS's native fuctions in an almost invisible manner. VB6 forms and picturebox's dont have the 'Tile & Stretch' capability's built in (unless i never found it?), and require API call's to perform the same task...
Sure, but to make a comparison, it would need to be executed in a loop, just as in the VB6 code I posted. I can't run your example on this machine, but I'm sure others can, and am quite interested in how the two compare.Quote:
Originally Posted by HanneSThEGreaT
But if I chose to make the example draw some sort of unusual pattern, the same in any language would require the same sort of algorithm. However, that is a test of a different nature - where the speed is largely determined by the efficiency of the algorithm (and the runtime), and not so much by the API, or how fast those functions are called. Such comparisons might be a little trickier, since the algorithm will no doubt be more subject to the coding style of the person who writes it. A simple loop is pretty straight forward for any language.
As stated earlier, I'll be putting together something which relies more (if not entirely) on VB itself, rather than API calls.