Am I on Candid Camera?... About to Flip Out

R

realolman

Regular
Joined
Feb 5, 2005
Messages
67
I have been programming with basic since MSBasic and the Timex Sinclair computer.
I have pulled my hair out and made it throught the transition from the OK prompt to Windows.


This .NET stuff has me completely baffled. How can you possibly make such a leap from Version 6 to .NET? Why would Microsoft feel the need to change it so drastically? It's like suddenly you know nothing. It's such a high level language, why would it be necessary to change it so much? "Print" doesn't even exist for crying out loud, and they don't even mention that it's gone!

I have bought books, gotten downloads, Nothing seems to make sense. Stuff directly from Microsoft doesn't even work.

Are people actually using this stuff, or am I on Candid Camera?

Everything written about it sounds like booshwah to me.

I am going to flip out now. Thank you very much.
 
Is this for a career move that you're learning .NET, or just to have fun? If it's just for fun, why upgrade? Heck, I'd stick with VB3 if you can find it. That thing was LIGHTNING fast.

When I go back to work on VB6 projects, I notice just how FAST a Windows program starts up compared to .NET in the IDE.

But, the changes to VB in .NET are definitely worth the extra effort. It was a bold move for Microsoft - and they've taken a LOT of heat. Trouble is, it's hard to support all VB users. Many professional VB users wanted a more robust environment and better OO support and that's what they got. Other users that cry for the days of QBasic got... well, they have emulators :)

I feel for you, but no one can force you to use .NET if you don't want to.

-ner
 
Thanks for your response. Especially touching was Pentium Guy's thoughtful and appropriate remark.

I know whining is unproductive, and Microsoft isn't going back to VB6 because I ( and apparently some others, judging by what Nerseus said about Microsoft taking heat ( how do you give Microsoft heat? I'd like to join them )) am unhappy about it.

Sometimes though, I think you stand back and look at a larger picture. You quit rasslin with some difficult code and wonder why it is so difficult.

Until I was older and looked back, I could not see what was taking place as I got older.

When some of you guys invest 20 years in it, and Microsoft ( who will probably be running the world by then... like they're not already ) makes large scale changes that appear to be unnecessary, and provides lousy ( albeit voluminous, wordy, poorly linked, robust, rich and creamy ) support, You'll be steamed too. I guarantee it.

It seems to me that considering the scope of what was changed, it would have been relatively easy to retain some of the earlier elements as genuine transition support.

"Print" is the first thing anybody ever did in programming... up until now.
What is so wrong with using a simple "print using" format to fill a form with tabbed, formatted data, that Microsoft felt the need to eliminate it? ... What ? did it take up too much memory?

Why not provide a NET framework replacement for MSComm... Please, before you inform me about it, get Sax.comm yourself and try to run the simplest tutorial "Your first serial port program"... one form, one text box, one button, six lines of code and it doesn't work... 3 build errors. Honestly, you'd think if Microsoft were sincere in trying to provide support that the simple tutorials would work.

I know.. I'm over the hill, I don't write games or nothin'. It just seems to me that they threw the Visual Basic baby out the window with the bath water.

Why not program in C?
 
Especially touching was Pentium Guy's thoughtful and appropriate remark.
Click to expand...
Heh. I'm there when you need me.

Yeah Microsoft isn't going to support VB6 anymore. They've moved on to "newer" stuff, but hey - the new .NET (2005) was built to accomodate vb6 users and get them .netting. It's a big step up to .net fom a COM based language such as vb6.

Honestly, you'd think if Microsoft were sincere in trying to provide support that the simple tutorials would work.
Click to expand...
You should see DirectX, from putting things in the wrong namespace (for only the vb.net version) to using abbreviations that aren't seen in directX for C#.NET (Ex: using D3DX instead of Direct3DX - I made a big rant about it on the DirectX forum earlier).

Well they're a monopoly, prices go up, quality goes down, and until some company can give them serious competition, I don't think they'll improve. But that's just me. Microsoft is great, but they're bad when it comes to maintanence (well maybe not for windows, but for .NET certainly) ... and maintenence is the most costly portion of the Software Development Life Cycle.

Why not program in C?
Click to expand...
Why not program in C++?

-The Pentium Guy
 
Splain yourself

What do you mean -what in God's creation is so difficult ? I must know less about it than I thought
 
Last edited:
If you following proper coding practices back in VB6, .Net should not come as such as shock to you. VB6 allowed you to program in VERY improper ways, which resulted in very heterogeneous codebases, since there are many different ways to do the same thing (most of them ugly). .Net cleans up the language and for the most part only retains the accepted "proper" way to do things.

So if you have been doing things the proper way in VB6, .Net is pretty straightforward. If you weren't doing things the proper way, then it will be a learning experience.
 
im struggling with MFCs and VC++ at the moment . Visual C# is a breeeeze.

realolman try the "dummies" or "complete idiots guide" books (if u like their style of writing) .. they helped me understand the basics :) and yep i swear by them

One of my classmates was 40 something programmed his whole life in COBOL [ yep it still is used ] he had a tough time trying to grasp C#.

I dunno much about VB .. but is trying to convert from a procedural language to an OO one thats causing such a problem ?
 
I think there is something to most of your replies. I paid around $600 for VB6 pro and when I saw that the standard edition was about $100 I thought there must be a rat in the wood pile. ( take your shot, Pentium Guy )

It seems that there is much more for the programmer to do with the .NET. Granted, you should have been declaring variables all along, but it's an easy trap to fall into. If you don't have to, why would you?

It used to be necessary to write code for everything (well, almost everything... you still had to walk uphill through the snow both ways to school every day ). What if Microsoft suddenly decided in a new version that you're going to have to write your own interfaces and they are not supporting gui forms any more. Do you want to start remebering and typing all your commands, file paths, and URLS also?

I'll bet there'd be some wailing and gnashing of teeth from people who think they're pretty hot right now.

The point of new versions should be that users can more efficiently apply the product to their own needs, not create more ways for Microsoft and third parties to suck more money out of customers, who seem to me deserve a little loyalty and respect for having bought their product.
 
If you are moving from VB6 then most of the changes are for the better, however if you so desire you can turn off Option Explicit (although this is only going to introduce the oportunity for bugs so why would you), continue to use the VB6 style of arrays, VB6 string handling etc.
Earlier you mentioned print has gone from the language, printing direct to the VB6 form rarely give a decent output and most definately didn't produce professional output.
If you relied on the mscomm control then there is a rs232 wrapper on MS's site that does pretty much the same thing but gives you more control and more capabilities to extend the functionality.
Moving to a more OO style give much more long term benefits in terms of reuse, maintainability and architectural design choices, some of these changes have required a fairly fundamental restructuring of VB. As well as one or two old favorites being cut though many, many old annoyances have gone as well (COM & the registry, poor file handling, COM and memory management, lack of registry support, lack of networking support, poor error handling spring instantly to mind).

As to the comment about
Why not program in C
Click to expand...
because it is a lot harder then .Net ;)
 
I am not a fulltime programmer and I loved VB6 and …

I cursed too when I first started up VB.net. Even a simple “Hello World” application (without the visual basic namespace) was quite a challenge. Yes, it’s true VB.net is new programming language and there are an awful lot of changes compared to VB6 but the advantage of all these changes became apparent to me when I converted the program that reads our XML codebooks and tests them.

Load Codebook VB6: 1min15sec
Load Codebook .net: 5 sec

Test Codebook VB5: 12min (all warnings boxes disabled)
Test Codebook .net: 1min (all warnings boxes disabled)

I am not saying that .net is like 12 times faster overall. Most of the speed increase came from switching from a datatable in vb6 to an arraylist of structures. What I wanted to say is if you write your code the way it’s supposed to be written you can get things done in .net that where previously unconceivable to VB6 programmers

And then I spend 2 months trying to understand the use of inheritance, Delegates and events. Even now I still have problems with some things but my level of programming is back to it’s normal level and I wouldn’t start a new program in VB6 even if my life depended on it.
 
I really don't want to be negative, but this is exactly what I have been talking about!
I downloaded the "rs232 wrapper" to which PlausiblyDamp refers, long before I hit this forum.

This is the description of the download from the MS site:

Overview

This sample demonstrates how to control a communications port from .NET. Since the .NET Framework does not support direct control of the Comm Port, a separate class is used that provides direct Win32 API calls. (Note: Comm Port is synonymous with COM Port, Serial Port or RS232 port.)

Featured Highlights

This tutorial demonstrates how to use the Comm Port to communicate. In particular, it discusses:

Testing to see if the Comm Port is available for use.
Using the Comm Port to communicate with a modem.
Use Win32 API calls to control communication with the Comm Port.

The fact is, it discusses nothing at all. There is no text or explanation of any kind.

These are the instructions for the "rs232 wrapper" :

Download and unzip the code into a directory of your choice.
Doubleclick the VB.NET How-To Using the Comm Port.sln file.
Click the buttons on the form to test the functionality.
Examine the code in the sample to understand how the code works.


There are comments in the code, but they are not particularly instructive.

Does this really seem like an legitimate effort at a tutorial to anyone? It doesn't to me.

Right after the aforementioned

Option Strict On

there are three imports:

Imports System.Runtime.InteropServices
Imports System.Text
Imports System.Threading

What I want to know from the tutorial - To communicate with a serial port, how does one know that these imports are necessary? Which ones are necessary and why.

In attempting to write any program, how do I know what references I have to make? How do I know what I have available to reference? Why do I have to reference anything at all? Why do I have to import a System.math ( is it called a namespace? ) in order to use a trig function? I never did before. How is that an improvement?

Now, my point here in this Random Thoughts forum is not necessarily to get serial port communication. I know I can use MSComm if I want to. Windows was originally supposed to be intuitive. The development environment and the language should be getting less complicated and more intuitive, but that certainly does not seem to be the case to me.

There are 600 + lines of code in the "tutorial" download that supposedly will communicate with a serial device, but Jukeboxes, and ISP s, and God knows what else, I can get with a mouse click... pre installed on my desktop from Dell whithout my even asking or wanting them.



If it's something Microsoft or it's third party lapdogs want to sell you it's easy... full of rich and robust non-information.

If it's something to show you how to use the stuff you bought from them for your own purposes, they act as if they don't know what is or is not relevent. After I sent them 5 bucks for the "Resource kit" that had no table of contents or options for a partial install, they sent me an email wanting me to rate my satisfaction with the purchase I made. Then I was linked to a survey about nothing but the packaging and shipping.
Whaddayou... U.P.S.? How about the content?

I believe Microsoft makes changes arbitrarily and makes it more complicated than it has to be intentionally. It's such a high level language, any combination of keystrokes could be translated into any pattern of ons and offs. There is no real reason to change programming elements. Why does it suddenly have to be called "TextBox.Text" instead of "Text1.text"? What's the big advantage in "ListBox1.Items.Add" over "List1.AddItem" ,that we need to change the whole language over it?

Pause in manifesto...
 
I totally agree. My bicycle was great. It was simple and it got the job done. I recently decided to upgrade to a car, what a nightmare! I have to stop at stop signs and red lights now. How ridiculous! Oh ya, get this: I have to buy gas and it's stupid expensive. Clearly my bicycle was better in every way.
Sorry, just being an *** :p

The majority of your complaints can be catagorized as standardization. And yes, Martha, that's a good thing.

.NET uses namespaces (another good thing) and those Imports statements are just shortcuts into those namespaces. You're not expected to know what exactly all the namespaces are and what they contain. That's what the MSDN Library and the search function of the Object Browser are for.

Why are you complaining about references? VB6 had COM (not a good thing) references out the wazoo.
 
Some of the changes are because .Net is not just the next version of VB but a new runtime that is common to all .Net languages, some compromises in naming convention have had to be made regardless of previous language experience. Hence why text boxes are now TextBox rather than just Text. Listboxes on the other hand behave differently because .Items is now a collection and can be acted upon using standard array / collection methods (for...each etc) rather than needing special handling compared to an array or collection declared in code. These changes bring a consistency to the language / runtime that means you do not have to remeber each way of dealing with a similar but implemented differently object model / control every time a 3rd party or different intrinsic control is used.

Class names are now fully qualified with a namespace - this aides the logical groupiong of related classes and narrows down the IDE's intellisense when you know what area you are looking in. They also allow duplicate classnames to exist without causing ambiguous naming conventions. Imports are just a shorthand way of refering to these fully qualified class names, nothing more; as to how you know which ones to use and which references to make - experience with .Net and use of the help files would be a start. Unless you were born with intrinsic knowledge of VB6 how did you know to use MSCOMM for serial port access, InStr to find a string inside another etc? Whenver you learn a new programming language or upgrade to a newer version there will be a learning curve, and admittedly going to VB.Net from earlier versions can be a steep one but the benefits are there when the move is made.

Changes like requiring math functions to be preceded by the math class are a result of .Net being Object Orientated, functions are now grouped logically rather than just existing in one large global pool i.e. Math functions are Math.<function>, String functions are String.<function>, Enviroment details are Environment.<function> etc.


In regards to the comm stuff (even though it wasn't your main focus) it took a quick search on google to find http://msdn.microsoft.com/msdnmag/issues/02/10/netserialcomm/
 
I believe I have already beat this into the ground. and most of you have been very patient and informative. For that I thank you.

I will look into the P/invoke article Plausibly Damp. Thanks. But I gotta tell you, this will be the third shot into something that seems to me should have been included as an easily applied tool in VB.NET. The fact that it was not, and that it takes all this effort to try to find a replacement is part of my beef.

Regarding the InStr thing, it was included in a very fine printed programming manual and listed in an alphabetical language reference that came with VB 3.

I believe Microsoft does not provide truly helpful documentation. For .NET I bought 2 language references and I can't make any sense out of them. They have even dropped the examples they had in each help topic.

As anyone who has done a quick search on Google knows... Quantity is not quality
 
Why not just quit learning VB.Net and switch to C# insted ... least u can tell yerself its a new language ( its not very different from VB.NET )

I've found some very good stuff on MSDN Dr GUI.NET :) .. imho MSDN is targetted at medium and experienced programmers ... and not if u want to learn somethin from ground up.
 
Last edited:
Thanks, TwistedM1nd, I wondered about that. I have a small bit of experience with C, and several years ago I got Visual C ( I don't remember how many plusses ). I didn't understand it either, so I went back to VB, and have been satisfied with it until now. This VB.Net reminds me a lot of that experience, and I wondered if VB.Net is not closer to some sort of C than it is VB6.

It is obvious that I don't have the experience or the expertise of most of you on this forum. My main area of interest has been trying to control machines and read real world events with computers. I am probably ignorant in that area as well, but I work with electronics as an industrial mechanic and it seems to me that there is a lack of availability in small scale, low cost automation. I believe there is a true void there. The stuff is either not very sophisticated, or the cost goes nuts right away, or is immediately tied to some particular vendor's proprietary protocol, and price gouging.

It was easier in the old days. I actually made some decent stuff. Drew circuit boards with an old black screened CAD progran, got negatives made, made some equipment to make circuit boards, made some boards that went right in an empty slot of an 8088 running GWBasic at 8MHz and a 486 computer running Windows 3.0 at 66 MHz. I could read encoders and Digital I/O.

One time when I was first getting the computer to read the encoder throiugh a board of my design and construction, I had it making some sort of little mark on the screen. This was the payoff of a long time, a lot of work, and for me, a fair amount of money. I was thrilled. I'll bet all of you know the feeling.

I called my wife to see this marvelous breakthrough and was happily demonstrating it to her. She looked around at my rat's nest, and at me and said, " You're out of your d*** mind. Look at you. Your hair's all messed up, your calandar's three months behind, and you're showing me some little bit of nothing on a computer screen."

Anyhow, programming has been very interesting, if not particularly producive or lucrative for me. I sorta felt like it was what "separated me from the apes", so I'd hate to lose it.

You think the MSIL will obsolete VB6?
 
Rtm

realolman said:
I have been programming with basic since MSBasic and the Timex Sinclair computer.
Click to expand...

I've been programming since the 8th grade in 1978. When moving to .NET I did the same thing that I've done since the TRS-80, read the manual. I've programmed in:
Assembler (Mnemonic machine language)
BASIC (Beginners All-purpose Symbolic Instruction Language) in many flavors
FORTRAN (Formula Translation)
COBOL (Common Business Oriented Language)
Pascal (named after the mathemetician Pascal)
RPG (IBM Report Program Generator)
SQL (Sequential Query Language)
PL/SQL (Oracle's Procedural Language extension to SQL)
VB .NET
C#
Whatever else I can't remember

Each time one of the first things I did was read the manual (the entire manual). Usually I found that any misgivings I had about a language or concept were allayed once I read the manual containing the author's and/or developer's intent. Often I would soon surpass my more experienced colleagues because I understood the breadth and depth of the language, as opposed to just using the language.

In the case of C# I downloaded the manual from Microsoft and read the entire thing through (even though I didn't understand it all). I then reread the introduction chapter several times until I grasped all the concepts being presented. Currently, I am in the process of reading each detailed chapter again now that I've got the idea of what C# and .NET are all about.

In summary, the way I have learned, mastered and become a proficient developer in each language was reading the manual. That's not to say I don't learn the secrets and tricks of the trade from others, especially forums. But to truly understand a programming language you need to read the manual. That way you can accurately contrast, compare and relate the language to others you have used, which then leads to a much more eloquent, efficient and, most importantly, effective programmer. :)

Links to the .NET programming manuals (all that I could fit, anyway) are in my signature.
 
Back
Top