🚀 go-pugleaf

hlr@aber.ac.uk (Hazel Marie Davey) writes:

>Dear Basic Users,

...<stuff trimmed>

>(3) With the discussions of compatibility in this news group coming to the
>    conclusion that new Basic's from Microsoft should be compatible with
>    current versions of C can we conclude that this will apply to 
>    VB for Dos? In particular is it compatible with DOS applications written
>    in QuickC for Windows? i.e can I write a front end in VB for Dos and LINK
>    rather than SHELL to my number crunching C program?

OR, (in my case), link to my serious Fortran number-crunching programs?  (C is
fine and all that, he said, nimbly ducking flames, but sometimes there's
nothing like Fortran for real computations!! :)  :)  etc.)  I'm using MS
Fortran 5.1, btw.


>----- 
-- 
"Moby" Dick O'Connor                         djo7613@u.washington.edu 
Washington Department of Fisheries           *I brake for salmonids* 

In article <1992Sep3.120034.11144@aber.ac.uk> hlr@aber.ac.uk (Hazel Marie Davey) writes:
>
>(1) Does VB for Dos have full control over COM ports as QB does
>    (I'm asking this because VB for Windows doesn't have any
>     direct support for COM ports).

Yes, Visual Basic for DOS has all the COM port support that QuickBASIC and
BC 7 has.

>
>(2) Does VB for Dos allow direct access to memory? I need INP and OUT
>    statements to set registers / read data from ADC/DAC/DIO(Digital In-Out) 
>    cards. Can I suspend updating of forms / screen etc while I'm talking
>    to my Data Acquisition card so that I don't lose any data? 

Yes, the INP and OUT statements are available to you.

>
>(3) With the discussions of compatibility in this news group coming to the
>    conclusion that new Basic's from Microsoft should be compatible with
>    current versions of C can we conclude that this will apply to 
>    VB for Dos? In particular is it compatible with DOS applications written
>    in QuickC for Windows? i.e can I write a front end in VB for Dos and LINK
>    rather than SHELL to my number crunching C program?

As always, you can write a number cruncher is the language of your choice and
link it in.  This is not necessarily an easy thing to do, but it's not hard
either IF you have the documentation on mixed-language programming that comes
only with the Professional Edition.

As far as being able to actually going into to another executable to execute
routines is concerned, I don't think that's possible in any context. Make the
other application into a library, and you're fine.

>
>(4) Does VB for DOS have a graphing add-on as part of either the standard or 
>    professional version to allow me to display XY graphs etc on the screen
>    and/or printer.

The Standard Edition does not have what used to be known as ChartLib, but
the Professional Edition does.

>
>(5) Speaking of printers, as VB for Windows uses the Windows printer drivers
>    what sort of printer support is offered by VB for DOS? i.e. can I print 
>    graphics from VB for Dos or am I limited to PRINT for text and
>    crude Print Screen for graphics?
>

I'm not very well versed on this. I do know you can print forms. Whether or
not you can print graphics is another matter.

>(6) If I shell from a VB for Dos program to something else is execution of 
>    the VB program suspended or does it continue in the background? Also,
>    once the application that I shelled to is complete can I easily 
>    discover whether or not it executed correctly?
> 

Because it's DOS you're working with, there's not going to be any background
processing going on. Your VB for DOS program will be suspended until the
shelled program has finished

>I appreciate that some of these questions are a bit deep but VB for Windows
>looked really good until I found that I had no direct COM support or low level
>access to data acquisition cards.
>

Understand that Visual Basic for DOS is a character-mode development system.
Because it's closely tied to DOS (rather than Windows) all of the things you'd
expect to be able to do can be done.  There has been no attempt to make it
look like Windows in the graphical sense. Of course, a great deal of effort
has gone into making VB/DOS and VB/Win as compatible as possible from the
code perspective. If you obey a few simple rules, code for one will work in 
the other.  Key to this is knowing what you can't do in Windows that you
can do in DOS. If you write code for functionality that is available on
both platforms, your code will be quite portable, including the look of
your forms.

I hope this information provides some of the answers you are seeking.


-- 
Frederick F. Freeland Jr.                        "Of all the things I've lost,  Microsoft Corporation                               I miss my mind the most!"   One Microsoft Way  
Redmond, WA 98052 (206) 882-8080                                                                                                                                internet: fredf@microsoft.com                                                   arpanet:  fredf%microsoft@uw-beaver.ARPA
uucp:     uunet!microsoft!fredf                                                                                                                                 Opinions expressed over this signature are my OWN and not those of my employer!