Tired of those boring character based
screens? Itching to use your mouse instead of cursor
or function keys? fileProGI is filePro's answer to that. fileProGI
is FP-Technology's latest attempt at a GUI interface for filePro,
and in many ways, it certainly succeeds.
I will not go into past GUI products as comparisons, and will
give a brief rundown of what filepro GI is,
is not, what it does, and some general impressions.
What it is not: fileProGI is not a windows
version of filePro. fileProGI is not a new language
or command set for old-time filePro developers to learn.
What it is: fileProGI is a true Windows client
that provides a runtime graphical interface to filePro 5.0 Applications.
First copy includes GIServer™, a server-side TCP/IP interface
between filePro 5.0 and fileProGI clients.
How it Works: fileProGI is comprised of
2 parts, GIServer and fileProGI. GIServer would be
purchased for the same application server your filePro data
and programs reside on. fileProGI client would be installed
on any TCP/IP networked windows client that you'd want to communicate
with that GI Server. The communications take place via TCP/IP
sockets, and therefore require a TCP/IP based network. the fileProGI
client stations can be MS Windows 9x, NT, 2000, or XP (sorry
guys, no wyse 60's here!). On the back-end you need filePro
version 5.x (recommended version 5.06 or higher), which has
the TCP/IP socket protocols built-in. If this sounds hard, it
is not - if you've already got a few windows PC's hooked together,
or are thinking about it, you're most of the way there! The
fileProGI client machines perform the rendering and talk, via
TCP/IP, to GIServer, which in turn talks to filePro 5.0. GIServer,
acting as a middleman, can either offer screen-scraping to old-style
screens or immediate access to new GUI screens, buttons, and
commands within that filePro 5.0 application. Note that because
it can screen-scrape old style screens, older programs become
GUI-enabled "automagically" and immediately!
Yeah, yeah, but what about the details? OK,
like I said, filePro GI is an overlay that rides on
top of filePro in 2 places, at the "client"
level (the user's PC), and at the "server" level (the
computer that actually stores the filePro programs and applications.
The two sides communicate with each other via TCP/IP, on a port
which must be dedicated to the application. If this sounds intimidating,
it is not - if your network is already running TCP/IP, all you
have to do is name an unused TCP/IP port and make sure that
the clients look for that port number. The default of port #4350
should work in most cases. Each
instance of fileProGI client communicates with a GIserver using
a TCP/IP socket and a detailed filePro messaging protocol which
controls the flow of screen presentation and data and handles
The Server: The computer that runs the filePro
GI server will also need the appropriate version of filePro
for that platform - be it Unix, Linux, Windows, Windows NT,
or whatever. The GI server itself is a program that converts
requests from the fileProGI client to and from filePro's character
mode on the back-end. It is not an interface to the data itself,
but rather an interface to the actual programs (d/rclerk, d/rreport,
dxmaint, ddir). This applies to the runtime programs only -
there is no support for the development programs (ddefine, dscreen,
dcabe, rcabe, deddef, dmakemenu).
The server computer houses the application startup, setup,
control, and user information. For anyone to use filePro GI,
they must login to the server using the fileProGI server login
- this means they need a user account setup for filePro GI and
note that this is independent of operating system level accounts.
Each user's setup file (stored on the server), is named for
that user, contains password, startup information, and other
variables. Note that this enables you to easily have different
user accounts start at different places within your application.
The basic login screen has user, password, and a configuration
button to setup address, port #, etc. This screen, including
splash logo, are customizable only with development kit.
What do you see when you login? The fileProGI
Client computer logs into the server and starts up in the menu
named in that user's configuration file. The menu that is seen
is an HTML rendering of the menu defined within the character
mode filePro's define menus program. From there, one can click
with the mouse on any of the menu choices. Choices that pull
up other menus go to similar screens. Anyone familiar with HTML
can customize the look and feel of the menu, add buttons, etc,
though some modifications require the purchase of the filePro
GI development package. Some preferences (such as whether a
user prefers to still see numbered/lettered menu choices when
in GUI mode, fonts, background, colors, etc.) can be turned
on/off via the toolbar.
Once a GI Client clicks to the point where he/she has drilled
down to where dclerk/rclerk (inquire, update, add), dxmaint
(index maintenance), ddir/dprodir (filePro directory), or pmaint
(printer maintenance), they get put into a new set of controls.
The built-in filepro screens from the character mode are replaced
by similar looking GUI screens, but again with mouse control,
better font choices, colors, etc. Any and all function keys
and/or single key choices are now clickable buttons on-screen,
some in familiar places, some with neat icons on the toolbar.
This is especially nice in browse windows - my only complaint
is the addition of non-standard scroll-bars, that do not work
the way they do in other windows applications.
The screens designed in filePro's character mode (define screens/dscreen)
are rendered in the GUI product without change - that means,
that if you don't change anything, you can start using the product
immediately. If you do start making changes, however, you'll
get a ton of new features.
Customize to your preferences and usabilty!
I find that I show a lot of prompts on the screen, many times
in reverse video - it is only a small change to code to enable
them as clickable buttons (think how many times you ask for
a Y/N confirmation!). Similar can be done with edit comments.
This is not my expected cursor path? I already
mentioned mouse works fine on menus and other built-in filepro
screens, but what about the mouse while in middle of your own
designed screens in inquire, update, add? How does it affect
cursor path? With no mousing around, fileProGI responds to the
normal cursor path as long as the user uses the keyboard to
navigate screen fields. Full when processing such as @WEF and
@WLF routines are executed as the user steps through the fields
using the keyboard. However, if the user uses the mouse to click
from one field to another, we can go two ways - either we skip
directly to the moused-to field, and the only when processing
that will be executed will be the routines associated with the
field the cursor was in and the when processing associated with
the field that was specified by the mouse click. Any when processing
that would have been executed if the user stepped through all
of the fields using the keyboard will NOT be executed. The other
way, we act as though user pressed <Enter> from each field
within the cursor path between the two points, and then any
and all @wef/@wlf processing in between doesget hit. See new
command MOUSE PATH. This area is a bit fuzzy tome and needs
testing to see how best to setup.
Right-Click mouse - even without the development
kit, you do get some add-ons here - built-in calendar and calculator,
cut & paste, and various GUI preference settings. If you
spring for the development kit, you can add a whole bunch more
features, customize as you see fit.
Browse Lookups - Browse lookups stay the same
- the only difference is that you can use the mouse and customize
the colors, fonts, etc. It is not the same as the windows drop-down
box. To replace a browse with a windows drop-down box, you need
the development kit to pre-supply the drop-down data with the
client computer configuration. This works well for static things,
e.g. yesno choice of Y or N, but for reference files that change
dynamically, this design is poor. You can rebuild these files
via a data exchange from server to client, from processing,
and again, such functionality requires the development kit.
The advantage of the drop-down boxes includes more windows functionality,
including type-ahead. My opinion is that the design here, of
storing drop-down info at the client rather than the server
level, is not well thought out and a shortcoming of the product.
Instant links to web and email: Instant WWW/URL/HTML
and email links are possible when they appear onscreen - just
not when embedded in data fields - that is to say - if a data
field contains www.cnn.com or firstname.lastname@example.org, you must
put it on the screen via a show statement in order for the fileProGI
client to recognize it as a clickable entity.
Help files: Your old inquire, update, add
text files work the same in the GI version. Menu help, however,
must be replaced with html. With the development package, you
can add in html templates, backgrounds, etc.
Getting much fancier: If you want to embed
images on your screens, call other windows applications, etc,
you need the development kit for this, too. It adds a messaging
command which calls to the client operating system, with screen
coordinates and what to do within them - there are many permutations
of it, including image display/view, text viewer and interactive
access to any windows application.
While it may seem that they force you to buy the developer
package to get fancy - if you are a developer yourself it can
quickly pay for itself, as it is a one-time purchase - you can
configure as many client sessions as you want - consider
it a toolkit.
here for more information on this from FP Technologies, Inc.
Click here to request
additional information on filePro GI