Visual Fortran vs. Pro Fortran
John Uebersax
software development project. I'm wondering if either is signicantly
better when it comes to designing menus and user-dialog boxes in the
application program.
Thanks in advance.
--------------------------------------------------------------------------
John Uebersax, PhD
web: http://ourworld.compuserve.com/homepages/jsuebersax
--------------------------------------------------------------------------
Duane Bozarth
John Uebersax wrote:
>
> I'm trying to decide between Visual Fortran and Pro Fortran for a
> software development project. I'm wondering if either is signicantly
> better when it comes to designing menus and user-dialog boxes in the
> application program.
I don't know what is with Pro Fortran, but if you think "Visual" Fortran
is Visual Basic with Fortran syntax--it isn't. The "Visual" part only
refers to the interface of the compiler to the MS Visual Studio IDE.
There are extensions included to allow use of the common dialog
controls, but no GUI designer of other such is included in CVF. One can
build what are termed "QuickWin" applications that provides a standard
window w/menus, etc., that can be modified to a certain extent, but it
is not a "full-blown" Windows app. Windows app's can be written, but at
the level of using the Win API directly, not a pleasant thing...
If that's your intent, then I'd suggest looking into Winteractor or GINO
or some of the other GUI builders--or even Tcl/Tk as a alternative way
to build the GUI and tie it to the Fortran.
HTH...
Petros Dafniotis
Visual Fortran is by Compaq & Intel (now) but Pro Fortran is from
Absoft. Note that there is also a product called Intel Fortran which
is different from the Visual Fortran.
None of the Fortran's above would be good for developing any
sophisticated GUI. For a simple GUI when you will not need DLLs (i.e.
you will have at the end a standalone executable), the Visual Fortran
offers a library called QuickWin which works like a miracle and it is
VERY easy for new programmers and reasonably customizable.
Your best bet is IMHO to:
1. use Delphi as the GUI front
2. use Tcl/Tk as the GUI front
Looking at the usenet you should be able to find plenty of examples of
"delphi AND fortran" etc. Kind regards,
Petros
---
Petros Dafniotis, PhD
pdafn...@yahoo.com
jsueb...@yahoo.com (John Uebersax) wrote in message news:<f6f3f967.03062...@posting.google.com>...
Catherine Rees Lay
Dafniotis <pdafn...@yahoo.com> writes
>John-
>
>Visual Fortran is by Compaq & Intel (now) but Pro Fortran is from
>Absoft. Note that there is also a product called Intel Fortran which
>is different from the Visual Fortran.
>
>None of the Fortran's above would be good for developing any
>sophisticated GUI. For a simple GUI when you will not need DLLs (i.e.
>you will have at the end a standalone executable), the Visual Fortran
>offers a library called QuickWin which works like a miracle and it is
>VERY easy for new programmers and reasonably customizable.
>
>Your best bet is IMHO to:
>1. use Delphi as the GUI front
>2. use Tcl/Tk as the GUI front
3. use a 3rd party Fortran library to write the GUI. Winteracter,
Ginomenu and I'm sure there are others, are available for both the
compilers you're looking at. This is often a good solution where it will
be difficult to separate an existing program into a GUI which calls
purely computational routines, with no GUI further down the call tree.
Both offer visual dialog and menu design, and they are much more
sophisticated than QuickWin.
4. use a custom system such as SansGUI (while it is a Fortran-only
solution like the libraries above, it works in a significantly different
way to them).
Different solutions are suited to different problems - I can imagine
recommending any of 1, 3 or 4 depending on the structure of the existing
program, and have personally used 1 and 3 for customer's code. (I've
never investigated Tcl/Tk so can't comment).
Catherine (I work for Polyhedron Software as a programmer, mostly
writing Windows GUIs, they sell both Visual and Pro Fortran and other
compilers, and also Winteracter and Ginomenu).
>
>Looking at the usenet you should be able to find plenty of examples of
>"delphi AND fortran" etc. Kind regards,
>Petros
>---
>Petros Dafniotis, PhD
>pdafn...@yahoo.com
>
>jsueb...@yahoo.com (John Uebersax) wrote in message
>news:<f6f3f967.03062...@posting.google.com>...
>> I'm trying to decide between Visual Fortran and Pro Fortran for a
>> software development project. I'm wondering if either is signicantly
>> better when it comes to designing menus and user-dialog boxes in the
>> application program.
>>
>> Thanks in advance.
>>
>> --------------------------------------------------------------------------
>> John Uebersax, PhD
>>
>> web: http://ourworld.compuserve.com/homepages/jsuebersax
>> --------------------------------------------------------------------------
--
Catherine Rees Lay
Paul Curtis
Catherine Rees Lay wrote:
Compaq Visual Fortran provides complete access to the Win32 APIs, and
one can create all-fortran
programs with any sort of complex GUI (and communications, and speech,
and networking, etc.)
features desired, with as little (or as much) effort as in any other
Win32-capable language. This requires
learning how Windows works, and typically developing a set of wrapper
functions to access the APIs,
but once over this barrier there are NO LIMITS to what can be done, and
it's all in Fortran.
The various commercial GUI packages (including "QuickWin") all entail
degrees of abstraction between
the limited options made available at the Fortran end, and the true
Win32 functionality, and the abstracted-
out items always turn out to be the ones you need. The proffered
initial time-savings (vs writing your own)
is illusionary, and will likely bite you (and your project) in the end.
David Frank
"Paul Curtis" <pcu...@kiltel.com> wrote in message
news:3F019A19...@kiltel.com...
>
>
>
> Compaq Visual Fortran provides complete access to the Win32 APIs,
and
> one can create all-fortran
> programs with any sort of complex GUI (and communications, and
speech,
> and networking, etc.)
> features desired, with as little (or as much) effort as in any other
> Win32-capable language. This requires
> learning how Windows works, and typically developing a set of
wrapper
> functions to access the APIs,
> but once over this barrier there are NO LIMITS to what can be done,
and
> it's all in Fortran.
>
Amen,
but I'm not sure what you mean by needing wrapper functions to access
the
apis.
http://home.cfl.rr.com/davegemini/get_file.f90
I just use regular interface statements to access the 4 functions
needed.
BTW, Catherine and others here were challenged to convert my source to
another F9x compiler but no-one indicated any success in doing so.
Its my opinion no Fortran compiler other than CVF (and MS FPS 4.0) has
syntax to allow such direct interfacing to C libraries.
Gary L. Scott
I would say that GINO V6 has 98% of all of the GUI and more pertinent,
3d graphics (open GL or native), charting, graphing, shading, ray
tracing, lighting, real-time video and motion features that 99.8% of all
Fortran GUI developers would ever need. And each new release adds even
more capability. On top of that it is highly cross-platform portable to
Windows, Linux, Unix, and OpenVMS. Why write an application that will
only run on Windows and would require a huge investment to port to
another OS? After having my primary computing platform rug pulled out
from under me at least twice over the last 20 years and having to
rewrite numerous tools each time, I decided that I would make all future
tools as platform independent as possible. At the same time I refused
to compromise on functionality.
A GUI builder is a superior solution if you have these concerns. Also,
I will not use one that makes no effort to be cross-platform portable.
This of course CAN limit the functionality that you can take advantage
of in your application a tiny bit because there is perpetual pressure on
Windows platforms for new features "feature-itis" (or more properly
access to more of the native API functionality) that may not exist
across all platforms, unless emulated (emulations/simulations are often
inaccurate). This method can produce GUI applications that can be
ported to any of the above listed OS' in most cases in less than an hour
(change some header files, possibly adjust for "look and feel" reasons).
--
Gary Scott
mailto:gary...@ev1.net
Fortran Library
http://www.fortranlib.com
Support the GNU Fortran G95 Project: http://g95.sourceforge.net
Gerald F. Thomas
and
> one can create all-fortran
> programs with any sort of complex GUI (and communications, and
speech,
> and networking, etc.)
> features desired, with as little (or as much) effort as in any other
> Win32-capable language. This requires
> learning how Windows works, and typically developing a set of
wrapper
> functions to access the APIs,
> but once over this barrier there are NO LIMITS to what can be done,
and
> it's all in Fortran.
>
> The various commercial GUI packages (including "QuickWin") all
entail
> degrees of abstraction between
> the limited options made available at the Fortran end, and the true
> Win32 functionality, and the abstracted-
> out items always turn out to be the ones you need. The proffered
> initial time-savings (vs writing your own)
> is illusionary, and will likely bite you (and your project) in the
end.
>
Hear, hear. Compaq's success in providing Win32 API access is partly
due to the basis Digital acquired from Microsoft when FPS was
discontinued and Visual Fortran as a fully-integrated part of VS under
license from Richmond happened. With the merging of CVF and Intel
Fortran into a plug-in to VS.NET, current users of CVF are in for some
changes including loss of the edge over competitive products such as
Lahey/Fujistu's and Salford's Fortran.Net.
Happy Canada Day,
Gerry T.
Gary L. Scott
And an actual decline in the level of "integration" with VS as compared
to CVF.
>
> Happy Canada Day,
> Gerry T.
Gerald F. Thomas
"Gary L. Scott" <gary...@ev1.net> wrote in message
news:3F01A799...@ev1.net...
>
> And an actual decline in the level of "integration" with VS as
compared
> to CVF.
>
What are you trying to say?
Catherine Rees Lay
<pcu...@kiltel.com> writes
>
>Compaq Visual Fortran provides complete access to the Win32 APIs, and
>one can create all-fortran
>programs with any sort of complex GUI (and communications, and speech,
>and networking, etc.)
>features desired, with as little (or as much) effort as in any other
>Win32-capable language. This requires
>learning how Windows works,
>and typically developing a set of wrapper functions to access the APIs,
I have a set of several hundred wrapper functions just like this. I
didn't write it myself. I paid experts who do nothing but work on API
wrapper functions to do it for me. They spent several years on it, I
bought it for the price of a few days work. I consider it a price well
worth paying, even though I have written Fortran and Windows API
programs for customers and so had already learnt how Windows API
programming works (decidedly non-trivial, by the way). And I can change
to compilers other than CVF should I need to, because those experts
wrote the same wrapper functions for other compilers too. They happen to
call it a library rather than a set of wrapper functions, but it works
just the same way.
>but once over this barrier there are NO LIMITS to what can be done, and
>it's all in Fortran.
>
My code is all in Fortran already! There's one extra layer between my
code and the Windows API libraries, but it no more matters to me what
language this layer was written in than what language the API libraries
themselves were written in.
>The various commercial GUI packages (including "QuickWin") all entail
>degrees of abstraction between
>the limited options made available at the Fortran end, and the true
>Win32 functionality, and the abstracted-
>out items always turn out to be the ones you need. The proffered
>initial time-savings (vs writing your own)
>is illusionary, and will likely bite you (and your project) in the end.
>
For QuickWin I couldn't agree more - you are highly likely to run into a
brick wall. 5 years ago I was writing complex GUIs using the Windows API
myself, and I would have been in complete agreement with you. These days
the commercial libraries are much, much more complete than they used to
be, having had many years of incorporating requests from people like me
and Gary Scott who are actually writing GUIs using them. There are
limits to what you can do, but these days they are at the level of
setting kerning values for your fonts. My projects simply don't need
that sort of access to the API, and nor I suspect do most people's. If
you really need access to the abstracted-out things which the libraries
don't do then yes, you're stuck with the Windows API. But the reason
these things haven't been made accessible is precisely because they're
the ones which people don't ask for - in practise, not in theory.
There's nothing illusionary about it. The time savings over using the
API directly are huge for the sort of GUI the OP asked for - all the way
through the project, nothing "initial" about it. I know. I've used both.
Catherine.
--
Catherine Rees Lay
Gary L. Scott
>
> "Gary L. Scott" <gary...@ev1.net> wrote in message
> news:3F01A799...@ev1.net...
> >
> > And an actual decline in the level of "integration" with VS as
> compared
> > to CVF.
> >
>
> What are you trying to say?
Statements have been made that MS was unwilling to transfer certain
licensing arrangements from Compaq to Intel which allowed Compaq (DEC)
to provide improved access to various tailoring "internals" as compared
to other products that claimed "integration" with VS. A complete
description of what this really means is beyond my ability (or memory).
It would appear then that all VS.NET products will offer roughly the
same, lower (how much is the question) level of integration. This in
fact may bother no one else but me. I can't actually say for sure how
much it will bother me though until I see the product.
>
> Happy Canada Day,
> Gerry T.
Gerald F. Thomas
> "Gerald F. Thomas" wrote:
> >
> > "Gary L. Scott" <gary...@ev1.net> wrote in message
> > news:3F01A799...@ev1.net...
> > >
> > > And an actual decline in the level of "integration" with VS as
> > compared
> > > to CVF.
> > >
> >
> > What are you trying to say?
>
> Statements have been made that MS was unwilling to transfer certain
> licensing arrangements from Compaq to Intel which allowed Compaq
(DEC)
> to provide improved access to various tailoring "internals" as
compared
> to other products that claimed "integration" with VS.
This is unmitigated spin (not on your part of course). It's fair game
that Microsoft isn't about to easily accommodate .NET interlopers who
are unwilling to fully integrate to .NET framework. Intel currently
claims that their Fortran compiler integrates to .NET. It doesn't. It
doesn't generate IL, use the CRL, allow multi-language development,
allow Web-based app creation, support Window Forms (drag and drop
Windows with widgets in Fortran) and if a CRL for a nonWindows
platform were to appear tomorrow then you would be stuck with Windows.
Indeed, the Intel Fortran compiler doesn't even offer F1 or online
help within the .NET IDE. Actually it doesn't even come with a single
Fortran sample to demo that the compiler even compiles. It ships with
a tutorial that speaks to getting started with Intel C++ and when you
reach the Fortan-relevant part you're referred to the Fortran
documentation. Not even Microsoft displays such distain and contempt
for its customers. Don't expect matters to change with the merging of
CVF and Intel. The resultant will remain a .NET plug-in as opposed to
a fully integrated Fortran compiler like Lahey/Fujistu Fortran.NET.
> A complete
> description of what this really means is beyond my ability (or
memory).
> It would appear then that all VS.NET products will offer roughly the
> same, lower (how much is the question) level of integration. This
in
> fact may bother no one else but me. I can't actually say for sure
how
> much it will bother me though until I see the product.
>
I'd encourage you to avail of the LF Fortran.NET release candidate
evaluation. It installs flawlessly into .NET 2003 and all the shipped
samples illustrating managed and unmanaged Fortran code work straight
out of the box.
The Canada Day fireworks have started.
Ciao,
Gerry T.
Gary L. Scott
I've previously stated that the competition has been re-opened with the
death of CVF. It may be that I follow the Intel path, but they must at
least equal the best competing product to "keep" my (CVF) business. I
also own Lahey LF90/95 and Absoft Pro so I am familiar with their past
offerings. I have previously downloaded LF Fortran.NET. In any case,
any path I take will require me to upgrade GINO so I won't take the
decision lightly (I have to upgrade through the bureaucracy at work as
well as at home).
>
> The Canada Day fireworks have started.
>
> Ciao,
> Gerry T.
Greg Chien
> This is unmitigated spin (not on your part of course). It's fair game
> that Microsoft isn't about to easily accommodate .NET interlopers who
> are unwilling to fully integrate to .NET framework. Intel currently
> claims that their Fortran compiler integrates to .NET. It doesn't. It
> doesn't generate IL, use the CRL, allow multi-language development,
> allow Web-based app creation, support Window Forms (drag and drop
> Windows with widgets in Fortran) and if a CRL for a nonWindows
I see CRL being repeated twice; therefore, worth correcting:
CLR - Common Language Runtime
For those who are interested in .Net on Linux (ABM :-), see:
http://www.go-mono.com/
--
Best Regards,
Greg Chien
e-mail: remove n.o.S.p.a.m.
http://protodesign-inc.com