[Lowfer] Basic / VB Issues

[John Davis]

>John opines:
>>
>>Porting to Visual Basic is a bit trickier than simply importing BASIC
>>code .... etc ...
>[PB: I don't understand how the above bears on Ed's problem. However VB
>and OOP leader Java can both be used in "procedure mode" aside from
>their full OO capabilities. That was the way I started with VB and still
>see commercial code doing the same. But Ed should know that VB is
>capable of more than that, its use is optional.


VB procedures don't simply receive keyboard input from the keyboard buffer,
nor can they simply output to screen.  That's how it relates.  One must
understand forms and at least a minimal set of controls for receiving input
and displaying output.  I have no doubt that Ed will master the concepts
quickly enough, if that's the route he chooses to take.  My point was and
remains simply that there's a bit more to it than importing code from BASIC
that was written for DOS.  (Doesn't have anything to do with OOP, either,
which wasn't even mentioned in my post.)

73,
John












>]----------------------
>  (Well, you _can_ ignore it, but that's
>perilous sometimes.)  Instead of program flow in the sense you're
>probably
>used to writing, you identify events that must be handled...which can
>be
>user input, Windows messages, or actions taken by code within the
>program or
>from another program...and then write code to handle them.  It's a
>rather
>different philosophy.
>[PB: Not necessary to consider this, as I understand Ed's stated
>problem. Object concepts may not be an issue here--have we overlooked
>KISS?
>]-------------------------------
>
>Since you're familiar with conventional BASIC, and since Microsoft
>isn't
>doing much (read: anything) with QuickBasic these days, you might be
>interested in a more modern implementation of the language anyway.
>There
>are even BASIC compilers that target the 32-bit console mode of Windows
>95
>and later.
>
>The one I'm most fond of is PowerBasic Console Compiler
>(www.powerbasic.com).  Strings and arrays are limited only by
>available
>memory.  You have access to functions in DLLs and Windows API calls.
>There
>are communications libraries (Marshall Software), graphics toolkits,
>etc.,
>available if you have a need for such.  Pretty powerful stuff.
>
>73,
>John
>-------------------------------
>
>PB: Not familiar w/ above but will look into it.
>
>Moreover, I suggest a cost effective way to try the VB route and locate
>a "learning" text, like the McFedries, they come w/ a CD having the
>compiler and solutions to text problems so one doesn't have to enter the
>text code. VB-5 is okay and there is newer VB-6, more stuff. Look for a
>new prior version at a discount books store/site.
>
>I would start with some simple stuff for a feel of it, fault the code
>for error interaction, etc. After that take a module of the Basic code
>and set it up as a subroutine/function in VB, make a caller and check it
>out. Keep the output simple, just text to the screen. This a great
>learning experience and VB is good at flagging errors, as I've found.
>
>However, Ed, I've not simply imported Basic into VB. Why? Simple. The
>GUI part of it is  too important these days, PCs, storage and
>conventional software are abundant and cheep. Hence, that's where all
>the fish are feeding. Given that I'd analyze it and likely rewrite.
>
>One other observation, VB is similar to C in that it's built on it,
>though notice there's no "V" in C, not as easy any how..
>
>Peter
>ps
>Ed, don't know the answer to your array max size question. I'll see
>what if I can find from sources or cohorts.
>
>
>_______________________________________________
>Lowfer mailing list
>Lowfer@mailman.qth.net
>http://mailman.qth.net/mailman/listinfo/lowfer