We have been working with Clipper since 1985 and have successfully migrated numerous mission critical applications from the DOS environment to the latest flavors of 32/64 bit Windows systems. But making it just work is not where we stop.
We focus on medium to large legacy applications where a substantial investment in software and practices needs to be re-evaluated. What is worth doing and how, and what not. Often a minimal functionality is all that is justified. Other times the dependencies and costs already involved are so extensive that a serious re-assessment is imperative. Re-assessment may show that parts of the system are obsolete and need to be discarded while others require a major overhaul in order to be in tune with modern technologies. This is where we also come in. We make sure you not only protect, but also leverage your previous investment as is warranted without the risk of remaining outdated. It is possible that lots of program code and business logic may be salvaged at a moderate cost.
Not only will we help you reach the wisest decision but we will be there to support and implement it as well.
Probably a negligible one because we take into account interface practices and respect them. Like the keyboard for instance which should behave as expected. A graphical interface is never an acceptable excuse for reduced productivity.
No, it need not be. Your application can be as advanced as you wish both in terms of interface as well as in terms of other capabilities like supporting multimedia or being web-aware or sending e-mails or texting messages to mobiles.
We make sure nothing is lost. On the contrary we will port all historical data to new databases if needed without any data loss.
Most likely. We aim at zero down time, gradual, safe and stress-free migration. Not all users will need to convert at once.
So if yours is not a one-off minor project but an important part of your business, we urge you to give us a call or write. We will more than happy to discuss your options.
We have a vast experience developing applications with Xbase++. We have strived for stable, user-friendly, efficient and powerful working environments for our users, where productivity and accountability counts. Our designs are engineered in a way which enhances developer productivity and speedy debugging.
We are always happy to discuss synergies with other developers.
Browser Framework. Past an initial menu or other selection means, our applications are browser-driven to a large extent. A consistent design is followed throughout. Root-menu entries are identical and all features one expects to find in one place invariably exists in all. A toolbar hosts several menu options including the editing group which handles the (modal) primary edit-form window (see example.) Any rectangular browser cell section either visible or not, can be marked. A marked section can be copied to MS-Excel for example, be printed or used otherwise by the application. Each browser’s layout is user configurable including column content. Popular layouts can also be shared.
Users can switch to any of the sorting orders available either via listbox choice or by clicking the corresponding column header. SEEKs can be performed on the active key by entering data on one or more key fields in a special window. An incremental search feature is offered if appropriate, incrementally limiting the view-able records a-la-Google. What’s more, search is not only case but also language insensitive. Finally the whole database can be searched by clicking a column then entering a value or string which should match any part of the corresponding field. Results appear one-at-a-time, forward or backward, and of course searching can be always interrupted.
Browsers are often where all the action is. Which is why powerful debugging tools are always accessible to developers or alpha testers from there (see screenshot WaDebug)
. Debugging not only involves code flow and variable content but also data environment and conditions that exist when it runs at a particular moment. If one wonders how this is feasible with Xbase++, take a look at this screenshot.
Developers need not specify any particular setup. One runs the app as usual either locally or at the customer’s site and users with developer’s credentials can then access the DevMode menu (see BrowserEng screenshot.) There are two types of “explorers”. One, not directly linked to the database is the window/object/iVar inspectors which allow you to select any open window and inspect properties including objects and other iVar content. The second is the Workarea debugger which is a usual browser containing information for all open workareas with all relevant data and order components. The user can select any workarea and at any point navigate within it freely in a relatively protected environment via a powerful DBU type browser. The W/A Debugger can also be invoked from within Alaska’s debugger command line so there is no limitation to the particular code execution point one wishes to explore. The DBU type browser is also used by our maintenance engineers to perform database magic (extract, replace, retrieve, audit etc.)
This is a glimpse of our proprietary (at least for the moment) Designer. It is all written in Xbase++ and we heavily rely on it. It is capable of producing extremely complex forms and reports and is linked to our reporting and query engine. Objects can output field info or other expressions but can also be frames, lines, variable grids, pictures, or even RTF boxes. Layers are also supported as well as overlaying fields and objects on standard form images.