Where is the Basic, in Visual Basic?

[SpacemanSpiff]

In considering the current Visual Basic offerings (.Net), I am struck by just how HOSTILE .Net is to the casual programmer... by this I mean, someone that needs to fire off a quick and dirty program... a simple interface... and not really become a "programmer". Us engineers have other things to do than to become full on code monkeys.

This is what BASIC used to mean.

You know, the B in Basic.

You could teach yourself just by looking at some code.

With .Net now at the front... it has many (most?) of the advanced OOP language features, making it vastly more complex.

So much so, I am considering learning VB6 instead (I hear it is good through Win8)

Since .Net has roughly the same learning curve as C++, C#, Java (or so I am told), what exactly it the *point* of VB.Net??? You certainly don't see a beginners language anymore, and I can't see people that need to do casual programming to support their primary activities (I have CNC LASER and robotics control that I have to accomplish, hardware AND software), being all that happy about dropping everything for a few weeks, in order to learn .Net in order to write a small program or two every year.

Again, I am NOT going to be a programmer. But I need some programs to do engineering. What should a regular Joe like me do, and why?

Is my notion of sliding "back" to VB6 a wise or a foolish choice in this instance? (I don't know VB6 or VB .Net, but I know various BASIC implementations as well as VBA)

Just doing a sanity check.

Thanks ever so much for sharing your opinion.

SMS

[DataMiser]

Well I would say that much of what you have said is incorrect. VB.Net does nto have the same learning curve as C++
Visual Studio is not a beginers language, It is a suite of languages ranging from Basic to C++

Both VB.Net and VB6 support the Basic language with many functions that date back to the original Basic versions and of course many new features have been added over the years that make things easier rather than harder. For example how much work would if take in GW Basic or BasicA just to get a mouse pointer to appear on the screen an then link it to the movements of the mouse? Forms, Windows, Databases on so on. many of these things are done now with little or no code where in the older forms of basic they would have taken many many hours of hard work on the part of the programmer.

VB6 has some issue installing under windows 8 but with some effort it will work. Not much point in learning it at this point though would be better to learn to use VB.Net instead.
If you know some basic then vb.net will not be that alien to you.

It is pretty simple to fire off a simple interface in either VB6 or VB.Net, much more so than it would be to do so in BasicA

[SpacemanSpiff]

Thanks for the feedback...

I guess where this notion of using VB.net falls short for me, is that I generally "program" by example... grab something that is similar to what I want, or has a feature I need, and I can then take care of business. I can do almost anything in VBA in minutes... I've done web browsers, camera controllers/frame grabbers, process simulators, kiosks, electrical test system controllers, report generators, visual inspection data stations, and on and on... and to tell you the truth, I'd stick with VBA, except my new robot controller and CNC controller needs VB6 or above.

With the structure in VB.net, I'm finding it VERY hard to see any "flow" to the programs themselves. The programming construction/style is alien.

I think if I go that route, I'm "stuck" having to stop my normal work... to learn the language. I was really hoping to avoid that.

Is VB6 closer to VBA than it is to VB.net? If it's closer to VB.net, then you're probably right...

SMS

[Españolita]

VBA is very similar to VB6. VB.Net is substantially different. Saying that, there are many "legacy" functions included in VB.Net so it is possible for a VB6 programmer to write a program in VB.Net without too much effort. The interface is not much different, you drag your objects on to your form, double click on them to write your code and then run it.
I would recommend investing the time (not too much really) to get used to VB.Net for 3 main reasons.
1. VB6 is no longer supported and VB.Net is the language most apps are being developed in.
2. VB6 can be made to run on Windows 8 but it is very likely that it will not run under the next operating system, whereas VB.Net will.
3. This CNC controller will accept VB6 or above, your next will probably only accept VB.Net or above.
By moving to VB.Net and skipping the "obsolete" VB6, you are future-proofing yourself and the programs you write for your machines.

[SpacemanSpiff]

Thanks much for the replies, guys! Very helpful.

On a more philosophical note....

Now that BASIC is really ASIC (_B_eginners need not apply), doesn't this leave a beginners programming language vacuum, in terms of Microsoft offerings?

[Españolita]

I understand your sentiments. I am also very comfortable with VBA and reasonably proficient in VB6. However, I have migrated to VB.Net and although I was overwhelmed at first, I quickly became used to it. Yes, there are still many things I can do in VB6 that I can't do (yet) in Vb.Net but I found the legacy functions very useful in migrating.
I do not agree that the beginners part is now obsolete, more due to the legacy functions than anything else. For me, the most difficult part for an absolute beginner is getting your head round the Object Orientated concept rather than the program logic or syntax.

[Doogle]

and to tell you the truth, I'd stick with VBA, except my new robot controller and CNC controller needs VB6 or above.

That's an interesting statement. I wonder what particular 'features' of VB6 are required that VBA cannot provide

[dilettante]

You might look at Microsoft's other .Net Basic: http://smallbasic.com/

[SpacemanSpiff]

That's an interesting statement. I wonder what particular 'features' of VB6 are required that VBA cannot provide

Actually, my private belief is that VBA can do anything And I have been tempted to try to use VBA... BUT the support/training/example code that are part of these systems are in VB and VB.net. The manufacturers won't support VBA development.

[dilettante]

VBA is an embedded automation technology. If you actually mean something like using Excel to "reach out" and try to act like a real programming tool using VBA then you can probably continue to do that using the same API these vendor(s) provide for VB6. You just won't get sample Excel documents (workbooks) to hack away at.

But there is no "VBA" in the sense of a stand alone development environment. It's a macro language that only works embedded in some host application that provides an object model and widget framework.

There are some 3rd party Basic tools you might consider, but I have no idea which ones support both COM and standard DLL entrypoint calls. I've heard "PowerBASIC" is very popular with the QBasic/VBA crowd though.

[SpacemanSpiff]

Exactly... Excel.

And yes, I am aware that it is probably POSSIBLE, but for reasons given above (and others), have decided to not even attempt it.

[dilettante]

Well if you are programming on Windows your choices are limited.

VBA and VB6 offer good support for COM and standard DLLs.

VB.Net and C# can bridge to these with some effort and use any .Net API a vendor supplies as well.

VBScript is hosted much as VBA is, but there are some basic hosts provided in Windows (WScript, CScript, MSHTA). However it has no direct equivalent of Declare so using standard DLLs requires a 3rd party bridging component.


Outside of these there are lots of choices, but be sure that any you choose can support the API technologies your vendors offer. Even Java can make use of COM and standard DLLs with enough effort - it's just a little frustrating: like using .Net only less pre-packaged for you.

VB6 might be your most logical choice, however it is hard to come by now and will have a learning curve. However you'll find that the IDE and most of the procedural syntax are both very similar to what you see in Excel VBA.

[dilettante]

2. VB6 can be made to run on Windows 8 but it is very likely that it will not run under the next operating system, whereas VB.Net will.

Hah!

We hear this every time a new version of Windows comes out. I'd be less surprised to see VB.Net disappear first, and don't let the screen door hit it on the way out!

[SpacemanSpiff]

We actually have hardware at the lab that have drivers that require Windows 2000!

So I'm less concerned with keeping up with operating systems... in fact, process reliability often requires that operating systems DON'T change, so VB6 and WinXP are going to be good for a very long time.

[Niya]

Since .Net has roughly the same learning curve as C++, C#, Java (or so I am told), what exactly it the *point* of VB.Net??? You certainly don't see a beginners language anymore, and I can't see people that need to do casual programming to support their primary activities (I have CNC LASER and robotics control that I have to accomplish, hardware AND software), being all that happy about dropping everything for a few weeks, in order to learn .Net in order to write a small program or two every year.

That is one lulzy statement. Don't kid yourself, VB.Net is no harder to learn than VB6 and most importantly, there isn't anything that can be done in VB6 that cannot be done much more easily in VB.Net with the exception of socket programming and even then, the VB6 Winsock control is an insult to network programming and should never have been created.

[DataMiser]

Another exception would be printing. In VB6 it is simply Printer.Print where as in VB.Net it is a bit more complex to say the least.

[Doogle]

the VB6 Winsock control is an insult to network programming and should never have been created.

That's a bit harsh. It may have some shortcomings but....

[DataMiser]

That's a bit harsh. It may have some shortcomings but....

I agree, the winsock control works well for what it is. I have one piece of software that I have been distributing for over 10 years now that uses a winsock control array to handle up to 25 clients at each location and has been running at 100s of sites for years with no issues at all. I have had many positive comments as to the speed and reliability of the program. The only compliant I have gotten is that it is not designed as a service so someone must be logged in to run it.

It took quite a bit of effort to get this type of stable TCP communication in VB.Net using the Sockets class but after much hard work and testing I have several clients that are using VB.Net code to talk to the server which is still using Winsock.

[dbasnett]

In considering the current Visual Basic offerings (.Net), I am struck by just how HOSTILE .Net is to the casual programmer... by this I mean, someone that needs to fire off a quick and dirty program... a simple interface... and not really become a "programmer". Us engineers have other things to do than to become full on code monkeys....

Thanks ever so much for sharing your opinion.

SMS

If by hostile you really mean different / changed, then you are correct. Could you post an example of some Q&D program that is being hampered by .Net?

I have been programming since..., well a long time. The changes and differences have been overwhelming at times, but the fundamentals are always the same, and will be so as long as the architecture is von Neumann based.

How are you communicating between the CNC / robot and the PC? Ethernet, USB, SerialPort, BlueTooth, etc...

BTW - don't call us code monkeys So I wish that programming languages would have stopped at IBM1620's SPS.

      BOTTLES OF BEER PROGRAM FOR THE IBM 1620 MODEL I
*
*       HAMMERS THE WHOLE THING OUT ON THE CONSOLE TYPEWRITER.
*
*       A MISERABLE WASTE OF TIME ON 10/2005 BY
*              CHUCK GUZIS   CHUCK @ SYDEX.COM
*
*       THIS CODE IS SHOWN IN ASSEMBLY-LISTING FORMAT WITH SPS MNEMONICS.
*       I HAVE SPREAD THE SPS FIELDS OUT A BIT FOR READABILITY.
*
*       THERE ARE SOME SPECIAL NUMERIC CHARACTERS:
*               ] = FLAGGED 0
*               J-R = FLAGGED 1-9
*               | = RECORD MARK
*               [ = FLAGGED RECORD MARK (NOT USED HERE)
*
*       IF YOU'RE GOING TO RUN THIS ON THE CADET, YOU NEED TO HAVE AT LEAST
*       THE ADDITION TABLES LOADED.  INDIRECT ADDRESSING IS USEFUL, BUT NOT
*       ABSOLUTELY NECESSARY (SEE NOTE BELOW).
*
*       EXECUTION STARTS AT 00402.
*
00402 34 00000 00102    START           RCTY                    ,,, RETURN CARRIAGE
00414 17 00626 ]0426                    BTM     DBEERS,*+12     ,,, SHOW COUNT
00426 39 00783 00100                    WATY    MSG2            ,,, OF BEER ON...
00438 34 00000 00102                    RCTY                    ,,, RETURN CARR.
00450 17 00626 ]0462                    BTM     DBEERS,*+12     ,,, SHOW COUNT
00462 39 00827 00100                    WATY    MSG4            ,,, OF BEER.
00474 34 00000 00102                    RCTY                    ,,, ZZZZIP...
00486 39 00847 00100                    WATY    MSG6            ,,, TAKE ONE DOWN
00498 34 00000 00102                    RCTY                    ,,, ZZZIP...
00510 12 00745 ]0001                    SM      BEERS,1         ,,, A DEAD SOLDIER
00522 46 00578 01200                    BZ      EMPTY           ,,, IF ALL GONE
00534 17 00626 ]0546                    BTM     DBEERS,*+12     ,,, SHOW COUNT
00546 39 00783 00100                    WATY    MSG2            ,,, ON THE WALL
00558 34 00000 00102                    RCTY                    ,,, ZZZZZIP...
00570 49 00402                          B7      START           ,,, DO IT AGAIN
00577 0
00578 39 00911 00100    EMPTY           WATY    MSG8            ,,, NO MORE BEER
00590 34 00000 00102                    RCTY                    ,,, ZZZZIP...
00602 48 00000 00000                    H                       ,,, STOP
00614 49 00578                          B7      EMPTY           ,,, IN CASE RUN PUSHED
*
*       SUBROUTINE TO DISPLAY BOTTLE COUNT AND EITHER *BOTTLE* OR *BOTTLES*
*
*       THIS ASSUMES THAT THE INDIRECT ADDRESSING FEATURE IS PRESENT, BUT
*       IF NOT, SIMPLY USE A "BB"(42) INSTRUCTION IN PLACE OF THE INDIRECT
*       BRANCHES.
*
00621 00000             DBRET           DC      5,0             ,,, RETURN ADD
00626 14 00745 ]0010    DBEERS          CM      BEERS,10        ,,, DISPLAY BOTTLES
00638 46 00710 01300                    BNL     DBEER2          ,,, 10 OR MORE
00650 38 00745 00100                    WNTY    BEERS           ,,, 1 DIGIT
00662 14 00745 ]0001                    CM      BEERS,1         ,,, JUST 1?
00674 47 00722 01200                    BNE     DBEERS4         ,,, NO, *BOTTLES*
00686 39 00767 00100                    WATY    BTL             ,,, SAY *BOTTLE*
00698 49 ]062N                          B7      -DBRET          ,,, EXIT
00710 38 00744 00100    DBEER2          WNTY    BEERS-1         ,,, 2 DIGITS
00722 39 00749 00100    DBEER4          WATY    BTLS            ,,, SAY BOTTLES
00734 49 ]062N                          B7      -DBRET          ,,, EXIT
00741 ]0099             BEERS           DC      5,99            ,,, BOTTLE COUNT
00746 |                                 DC      1,@
00747 0
00748 0042566363534562  BTLS            DAC     8, BOTTLES
00764 0|                                DAC     1,@
00766 004256636353450|  BTL             DAC     8, BOTTLE@
00782 0056460042454559  MSG2            DAC     8, OF BEER
00798 0056550063484500                  DAC     8, ON THE
00814 66415353030|                      DAC     6,WALL.@
00826 0056460042454559  MSG4            DAC     8, OF BEER
00842 030|                              DAC     2,.@
00846 6341524500565545  MSG6            DAC     8,TAKE ONE
00862 00445666552300                    DAC     7, DOWN,
00876 5741626200496300                  DAC     8,PASS IT
00892 4159566455440020                  DAC     8,AROUND -
00908 0|                                DAC     1,@
00910 5556005456594500  MSG8            DAC     8,NO MORE
00926 42454559030|                      DAC     6,BEER.@

[RyderS]

That is one lulzy statement. Don't kid yourself, VB.Net is no harder to learn than VB6 and most importantly, there isn't anything that can be done in VB6 that cannot be done much more easily in VB.Net with the exception of socket programming and even then, the VB6 Winsock control is an insult to network programming and should never have been created.

I don't know... I just got VB6 LE, installed it, got an example of TCP/IP chat... and it is fully comprehensible to me. Easy to follow the code and the flow.

I have tried the same thing with Visual .Net, got a simple TCP/IP chat example, and can't make heads or tails of it.

Real world example. Results with VB6, failure with .Net.

Again, in the engineering world, where work has to be done, on schedule, with code that supports those activities, results are all that matters. .Net being theoretically as easy to use as VB6 won't cut it.

[techgnome]

don't call us code monkeys

Yeah! We're "Compilable Instruction Simians"

In all honesty, I don't think VB has been very "BASIC" for some time... I remember making the transition to VB3 for the first time... at the time I didn't think it was all that Basic any more. transitioning from procedural programming to event programming was the hardest thing for me to grasp... ever. Even OOP/OOD came easier for me than the concept of events... "OK, I get it that when I click this button, this code runs... but where the heck is the ***** code that says 'if button clicked, run this code' ... " YEah... I spent three weeks going around and around and around on that one...


an astute classmate of mine back in the days of tech school (oddly the AF was kind enough to prepare me for just about everything but VB) noted that when you get right down to it, all languages are the same... they all have variable declarations, they all have some kind of loop structure, control structures, blocks, conditional statements and the same basic data types... they only differ in syntax.
I tell you it was a light bulb going on... that was my ah-ha moment. With the exception of my struggle with event-driven programming, after that moment, picking up new languages has been fairly simple... except Perl... that still confuses me... but I think that was the point behind it, to be as confusing as possible .. but picking up C++, PHP, even C# ... I may not be fluent or as quick in those languages as I am in VB, I can still read code and understand what's going on.

Another exception would be printing. In VB6 it is simply Printer.Print where as in VB.Net it is a bit more complex to say the least.

Yes and no... reason it isn't as simple as it used to be is because you have more control... things that used to be difficult with the old printer object are now easier... it allows for greater control then previously possible... so, yeah, it takes more code than it used to. That's why I simply go with a reporting too to take care of all that for me.

In terms of VB classic... VBScript is probably the most stripped-down, simplest form of VB. VBA would be the next step up from there. And then the next step up is VB6. Since VBA is basically a subset of VB6, anything you can do in VBA is going to be supported in VB6 ... mostly... there are some areas where it's not so direct, since VBA runs in context of Office, there are some things you have access to that you don't instantly have access to in VB6... at least not until you add the appropriate references.

-tg

[RyderS]

If by hostile you really mean different / changed, then you are correct. Could you post an example of some Q&D program that is being hampered by .Net?

I have been programming since..., well a long time. The changes and differences have been overwhelming at times, but the fundamentals are always the same, and will be so as long as the architecture is von Neumann based.

How are you communicating between the CNC / robot and the PC? Ethernet, USB, SerialPort, BlueTooth, etc...

BTW - don't call us code monkeys E]

We're connected via LAN... to both machine vision systems, and the robots themselves.


"Code monkeys" was meant only with the greatest love and affection

We use the term here at work to refer to the engineers that got stuck writing code more than doing their engineering job.

I don't want that to be me


What I see is that programs that stray farther from plain spoken language are harder to learn/comprehend.

BASIC used to be at one end of the scale, assembly at the other, and everything else in between.


I was looking at VB6 examples this weekend, and I can "see" the design intent in the example, and comprehend all of the code, even though I am not "up to speed" with the language.
Similar .Net examples are simply incomprehensible to me.

In practical terms, since I have to get *results* in short order, investing the time necessary to develop a little proficiency in .Net may turn out to be impractical.

I understand that one can write code in an older (traditional?) BASIC sensibility in .Net, but as I said before, I have to stand on the shoulders of giants... look at the code of others, and adapt it for my own use. This is a very typical learning mode, and gets me from a to b in rapid fashion.

Those well versed in .Net write code that conforms to a vastly more complex model.

In another thread, I asked for an example, of as few lines of code as possible, to show TCP communications in .Net.

Nobody offered this up... but I was pointed to a supposedly "simple" TCP chat program. Three forms and I think about 6 or 7 code modules later.... I'm banging my head on the wall.

I'm of the mind that opening a port on an address and sending a string should take only a few lines of code. With VB6, I have now demonstrated that I can do that. It took minutes.

No such success with .Net

And yes, we can all agree that if I learned .Net, then it would (by definition) become vastly easier...

Notice how the iPhone doesn't need a manual? It is comprehensible as is. You don't need to study it. You just use it. I find VB6 is a lot closer to that paradigm, and I think there is a legitimate need for languages that operate that way. It's not just programmers that need to control their hardware.

Regards,

RS

[dbasnett]

The fundamental concepts of event programming and multi-programming / threading have also been around a long time. What was hard for me was that you could only diddle with controls on the UI thread and all of the BS that went along with that. My past kept fighting with it. In the old days if multiple processes wanted to share a resource it was up to the individual to make certain that only one process at a time accessed it. I still don't like it. I wish that MS had just put a caveat on all the controls that said don't access the control from multiple threads simultaneously.

[dbasnett]

There is a company in the UK named Matrix Multimedia that has a product called FlowCode. I can't write PIC code, but I learned FlowCode quickly, and it knew how to write PIC code. They have the fundamentals down; variable declarations, loop structures, control structures, blocks, conditional statements, and basic data types. Almost all of it is done drag and drop.

[DataMiser]

For comunicating over a lan the Winsock control in VB6 is much easier to grasp than the Sockets class or TCPListener/TCP Client classes in VB.Net and for simple projects the Winsock control will do but the classes in vb.net are much more powerful and give you much greater control.

Speaking of older versions of basic the only version of VB that resembles basic is VB For Dos. It is basically like Quick Basic with a seperate forms designer added in for the visual part. VBDos gives you the option to write programs with or without using the Visual designer. If you stay away from the visual part then it is totally Basic. Even after programming in VBDos for quite some time VB3 had a bit of a learning curve after which VB 5 and 6 where not hard to pick up. VB.Net again had a learning curve and I still use VB6 for many projects, especially those I do for my own uses but it only took a few hours to see that there were things that could be done easily in VB.Net that would be a nightmare in VB6 and others than were simply not possible in VB6.

The communications via TCP was difficult to get right using the sockets class but once I managed to get it right it is now just a class I drop into my programs and is even easier to use than the winsock control in VB6 while still allowing me to control things that were not possible using the control and with a side bonus of being able to use the same class on mobile devices as well.

[RyderS]

There is a company in the UK named Matrix Multimedia that has a product called FlowCode. I can't write PIC code, but I learned FlowCode quickly, and it knew how to write PIC code. They have the fundamentals down; variable declarations, loop structures, control structures, blocks, conditional statements, and basic data types. Almost all of it is done drag and drop.

Just had a look at FlowCode...

Impressive. Thanks for this... (as I also have to code for Arduino at times)

[dbasnett]

Just had a look at FlowCode...

Impressive. Thanks for this... (as I also have to code for Arduino at times)

I had v4 of FlowCode and was impressed, but as I said I didn't know PIC coding so it didn't take much. I managed to create an RS232 application with all kinds of inputs, and I even had a clock that was fairly accurate that ran on the board. Good luck!

[RyderS]

My past kept fighting with it.

I sure hear that, brother. Since I can't be a programmer full time (or anything close to that), the evolution of languages has out-paced me... and my past becomes a heavy anchor. It's harder to reorient your thinking than it is to start fresh, I think.

[RyderS]

My past kept fighting with it.

I sure hear that, brother. Since I can't be a programmer full time (or anything close to that), the evolution of languages has out-paced me... and my past becomes a heavy anchor. It's harder to reorient your thinking than it is to start fresh, I think.

[ThEiMp]

In considering the current Visual Basic offerings (.Net), I am struck by just how HOSTILE .Net is to the casual programmer... by this I mean, someone that needs to fire off a quick and dirty program... a simple interface... and not really become a "programmer". Us engineers have other things to do than to become full on code monkeys.

Well I have made a special form of Visual Basic, BASIC, Pascal, C++, DHTML, PHP and Director typed programming language...

!! Click Here !!
PS: Just wait for the newer versions of the Build to be posted on the Website, by me!!

[Niya]

Another exception would be printing. In VB6 it is simply Printer.Print where as in VB.Net it is a bit more complex to say the least.

Oh ya, forgot about that one...printing in VB6 can be done with like 2 lines of code.

That's a bit harsh. It may have some shortcomings but....

I didn;t think I was harsh enough.

I agree, the winsock control works well for what it is. I have one piece of software that I have been distributing for over 10 years now that uses a winsock control array to handle up to 25 clients at each location and has been running at 100s of sites for years with no issues at all. I have had many positive comments as to the speed and reliability of the program. The only compliant I have gotten is that it is not designed as a service so someone must be logged in to run it.

It took quite a bit of effort to get this type of stable TCP communication in VB.Net using the Sockets class but after much hard work and testing I have several clients that are using VB.Net code to talk to the server which is still using Winsock.

I wrote an auto update app a few years ago in VB6 that composed of a client and a server. The server was responsible for updating instances of software that resided on its own private network. Its a fairly complicated piece of software with its own protocol of my making but at its heart it was basically a file transfer. The fact that it could transfer files was particularly useful so I was being asked constantly to add features to it that related less to updating software. Problem was, the program was hacky. This thing was truly a nightmare to extend. I mean it worked and has been stable and without crashes for years but it has become unmanageable. Its no longer safe to go tinkering around in its code. It can be easily broken. But the really stupid thing was the fact that its hacky nature was a necessity. In hindsight I realized that I should never have attempted this in VB6. The source of my problem revolved around the fact that VB6 was incapable of multi-threading. Couple that with the fact that that the only way to get data was to wait for the DataArrival event and without multi-threading, it means that you could only receive data while the there were no functions or subs currently executing. This makes implementing a protocol very difficult. DoEvents became a necessary evil and as a rule I could not use loops extensively. In place of loops I had to use Timers and maintain loop like states using class level variables. This was the most frustrating thing about the whole experience. When I had to use loops, DoEvents and busy-waits became necessary. DataArrival and DataSent would not fire without it. Reentrancy problems caused by DoEvents, plagued me to near insanity. I wouldn't wish this on my worst enemy.

Recently a mysterious problem began showing up. Its transfer rates were reduced severely. It was transferring at something like 10 bytes per second. I was asked to fix that but I knew in my heart that the chickens would come home to roost eventually. It worked well for years but it was such a patch job of a program that I wasn't the least bit surprised. Nonetheless I sure as hell wasn't going back in there to fix anything. Trying to debug a program that feigned multi-threading using DoEvents is not a trivial thing to do.

So, I started working on a VB.Net version of this. In fact its my current project and let me say the results so far have been spectacular. Features I could only dream of implementing in my VB6 version were natural and elegant to implement in VB.Net. Multi-threading ensured I could receive data anytime without using DoEvents to yield. That bit was really key. This new version while complicated is much much cleaner and easier to extend than its predecessor and I didn't have to use any crude DoEvents hack to get something to work. It was beautiful.

To be fair though. If I had to do it again in VB6, I think I could do it without DoEvents. It would have to be completely asynchronous and I have to make use of many more Timers and instead of using single functions and subs to do simple communication tasks like sending a list of files, I'd have to make entire classes instead because implementing looping semantics while allowing yields for DataArrivals and DataSents to be raised would require Timers and class level variables. This would make the implementation far more bloated than its VB.Net counterpart but it would be cleaner. Point is, in this case there is no escaping how inferior VB6 is to VB.Net.

I don't know... I just got VB6 LE, installed it, got an example of TCP/IP chat... and it is fully comprehensible to me. Easy to follow the code and the flow.

I have tried the same thing with Visual .Net, got a simple TCP/IP chat example, and can't make heads or tails of it.

Real world example. Results with VB6, failure with .Net.

Again, in the engineering world, where work has to be done, on schedule, with code that supports those activities, results are all that matters. .Net being theoretically as easy to use as VB6 won't cut it.

It wasn't easy for me too. In fact at first I would have settled for similarly simple control like the one in VB6. With multi-threading in VB.Net I figured I could mitigate at least some of the problems I had with it in VB6. I mean Winsock in VB.Net looked really scary.....but alas, know how long it took me to figure out how to use Winsock.Net ? Something like 1 1/2 hours....yes thats right. It really wasn't that complicated after all. I'm sure you could at least spend an 1 hr to learn something new despite the urgency. I was thinking like you when I first came upon Winsock.Net but when I started using it I realized why they didn't bring back the simplicity of the VB6 Winsock control.....it wasn't good for serious network programming. Winsock.Net is far superior. The added complexity is quite worth it in my opinion.

[FunkyDexter]

I can't help feeling we've gone somewhat off topic here and are exhibiting exactly the problem the OP is experiencing. He's struggling to get simple examples to work from so drowning him in the relative merits of multi threading in VB6 and .Net has probably just fried the last few brain cells he's got left.

Given this statement:-

I guess where this notion of using VB.net falls short for me, is that I generally "program" by example... grab something that is similar to what I want, or has a feature I need, and I can then take care of business

...I suspect RyderS hit the nail on the head right here:-

I understand that one can write code in an older (traditional?) BASIC sensibility in .Net, but as I said before, I have to stand on the shoulders of giants... look at the code of others, and adapt it for my own use. This is a very typical learning mode, and gets me from a to b in rapid fashion.

Those well versed in .Net write code that conforms to a vastly more complex model.

VB.Net is capable of writing code every bit as simple as VB6 or VBA ever were. In fact, it contains their libraries (with a few very minor ommissions) so you can write VB6 code in .Net if you wish. There's also no need to write object orientated code in .Net, it fully supoprts modular procedural code. Hell, it'e even still got GOTO in it so you can get really retro and pretend it's the 80s if you want to.

Your problem isn't that the language isn't simple enough, it's that the examples you're finding are too complex. You probably don't care that the MVP pattern will allow greater separation of responsibilities and enable dependency injection for test driven development. You probably do care about how to write a loop that will exit when you want it to, a bit of file handling and how to talk to your CNC's API. With that in mind I'd suggest that your best source of knowledge is probably forums like this one. Instead of going looking for the examples you want, get onto the .Net forum and ask for them. Be prepared for the fact that just asking for code outright tends to get a bit of a cold shoulder because people like to think your making an effort yourself (we get way too many students asking us to do their assignements for them)but, as long as you explain your situation, aren't afraid to admit you're a noob (we all were once) and are polite you'll generally get the the help you need.

Or you could indeed continue to use VB6. I'm not sure I'd recommend it because I think you'll find .Net every bit as easy as 6 for a quick bit of hacking once you've learned the basics (which won't take long). On top of that .Net is likely to offer you much more in the long run. But I still do some work in VB6 because it's not worth the effort to migrate some of the stuff I've got. I just live with the risk that it might get dropped at some point.

!! Click Here !!

Do NOT click there! Trust me, just don't.

[dbasnett]

The OP made a statement, "...someone that needs to fire off a quick and dirty program." If the OP would post an example it would help us understand the issues. What is quick and dirty?

[dbasnett]

BTW - Where can I get a copy of VB6? Is it free? Is it supported by MS?

[DataMiser]

You can get it from Microsoft or you may be able to find it on the Net.
No it is not free.
No it is not supported.

[RyderS]

I can't help feeling we've gone somewhat off topic here and are exhibiting exactly the problem the OP is experiencing. He's struggling to get simple examples to work from so drowning him in the relative merits of multi threading in VB6 and .Net has probably just fried the last few brain cells he's got left.

Yes, you understand the situation entirely... and I have brain cells left, but they are reserved for hardware design/Cad/Fabrication... and robot native code and machine vision scripting.

One of the reasons I ***LOVE*** VBA work, is that the examples are plenty, *and* they tend to use less sophisticated methods/structures. It probably doesn't promote the best programming style, but is generally laid out right in front of you in a single module and maybe a userform.

You set up a little control structure, bang in a few standard interface objects, slap some logic on top of that, and you're golden. It's not a platform to run a global enterprise from, but it tells a robot what to do just fine.



Someone asked for an example of what's going on...

Well, the robot has it's own language. I've had to learn that. BUT this language has no interface capability... other than a console for text. The interface implementation is available through VB...

So a pretty front end for manufacturing technicians to use is required... buttons, text boxes, images, check boxes, all that jazz. Select the program you want to run, a couple of options, then go. Not much more than that.

BUT...

Additionally, we have an automated electrical test system... code that drives test instruments... it generates pass/fail data and measurement data, among others.

Depending on the test results, the robot might need to do different things... perform a re-test... place a part in a reject bin, whatever....

This means that the robot and the test system have to be able to have a very simple conversation... TCP style, over the lan. "ready", "fail", "retest", "task complete", "serial:1234", etc.

Finally, vision systems also have something to say. These cameras have their own IP addresses, and they need to be told which of their internal "recipes" to run, and to report back "pass/fail" and OCR data (they know how to read barcodes, for example)



All of the hard parts are coded in the robot's native language, the perl test code, and the vision system recipes.

I want to tie this all together at a single interface... graphical, intuitive... and simply coordinate a conversation for all of these activities.

Once I have comms working fine, the rest is a walk in the park.

So, I dive into .Net, trying to find the most basic, stripped down TCP code... and leverage that. The best working example I could find has three forms and several modules. I can see things happening in the code... but attempts to condense/alter things to work for me end up breaking everything.


Contrast: I have VB6 sending things to and fro with ease. Literally a few lines of code... a couple of events.




I hear what people are saying... that stepping up to .Net has rewards... being overwhelmed with the .Net implementation of a TCP socket is a small price to pay for its greater power for good in the universe... and I *am* trying, but learning .Net, the proprietary robot language, and the proprietary vision system scripts and command set all at once is overwhelming.

[Doogle]

VB.Net is capable of writing code every bit as simple as VB6 or VBA ever were.

That's where I'm going wrong, I didn't realise that it wrote the code for you (tee hee)

As an ex-Engineer, I understand OP's issues, but one can't stick one's head in the sand and expect everything to be 'as it was'. Time moves on and we have to adjust. Unfortunately that might mean a struggle up a learning curve and cost, but ..........

I suppose there's still some PDP11s out there whirring away doing exactly what's required of them day after day but one day, well who knows?

[RyderS]

That's where I'm going wrong, I didn't realise that it wrote the code for you (tee hee)

As an ex-Engineer, I understand OP's issues, but one can't stick one's head in the sand and expect everything to be 'as it was'. Time moves on and we have to adjust. Unfortunately that might mean a struggle up a learning curve and cost, but ..........

I suppose there's still some PDP11s out there whirring away doing exactly what's required of them day after day but one day, well who knows?

There is NO such expectation.

BUT, the point of BASIC, with a "B" was to fill a particular niche, which to my way of thinking, it is failing to do as implemented by MS. Other languages are available with the more powerful and complex structures... so let the power programmers use those... and not co-opt BASIC, and shove it into the company of C#, C++, etc.

Here is an article that I think has merit: http://msdn.microsoft.com/en-us/magazine/jj133828.aspx

[Niya]

That's where I'm going wrong, I didn't realise that it wrote the code for you (tee hee)

As an ex-Engineer, I understand OP's issues, but one can't stick one's head in the sand and expect everything to be 'as it was'. Time moves on and we have to adjust. Unfortunately that might mean a struggle up a learning curve and cost, but ..........

I suppose there's still some PDP11s out there whirring away doing exactly what's required of them day after day but one day, well who knows?

I hear that brother. Its funny, from my almost fanatic belief in .Net as a progressive technology, I'm sure it would surprise many of you that I was among the most adamant in my refusal to move from VB6 to VB.Net. You had to hold a gun to my head to move. I can't remember what finally got me but I do remember cautiously putting my foot in the .Net world only to be sucked in by how easily and quickly I can get the most ridiculously simple tasks done in VB.Net.

Gone were days where I had to use ugly boilerplate "Redim Preserve" code to simply add items in an array, there was List(Of T). Gone were the days where I had to hunt constants in C++ header files for use in an API, the most common things I needed the Win32 API for were implemented natively in the framework. Gone were the days where I couldn't create a control when I want and place it where I want, .Net allows you to instantiate controls just like any other object. Gone were the days where I had to write functions that altered arrays multiple times for each type of array, .Net had generics. Even without generics, reflection could be used. Gone were the days where I had to alter the behaviors of controls by repeatedly copying and pasting event handling code every where I wanted the behavior, I could place the behavior code in one place using inheritance.......I could go on and on, but I'll leave it at that. The point is, I am now left to wonder, how in God's name I could have lived without this.

To be fair though, there is a great downside. If the day comes where I may need to program for some other OS like Linux or MAC I probably couldn't. The Visual Studio IDE and the .Net framework makes everything so comfortable and clean that I doubt the development infrastructure on other platforms can measure up. After getting used to such comforts it may be a great pain to use anything that falls short. As of now, its really a royal pain in my rear to code anything in VB6 despite the fact that I've way more experience using VB6 than VB.Net. Visual Studio and VB.Net spoils you rotten....ain't that something.

[Niya]

Here is an article that I think has merit: http://msdn.microsoft.com/en-us/magazine/jj133828.aspx

What a ridiculous article. This in particular is laughable:-

Visual Basic 6 accomplished its goals by abstracting away the complexity of the underlying Windows OS. Simple things were very simple to accomplish. On the other hand, complex things, such as dealing with threads, were impossible. My rule of thumb for Visual Basic 6 was: if I couldn’t do it within 10 minutes, I couldn’t do it at all.

Imply that this isn't so in VB.Net. This article reads like it was written by someone with years of experience in VB6 but only dabbled in VB.Net for all of 5 minutes. Its bias is utterly insulting.