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 menu interaction.

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 george@whitehouse.gov, 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.

Click here for more information on this from FP Technologies, Inc.

Click here to request additional information on filePro GI