Adding Help to Existing Applications
Storing the Help Text in Rochade  

Integrating Rochade into Existing Applications
Not just Help, but Metadata too!

 
One client asked if there was a way to add help to existing VB and C++ applications, where the help information was stored in their Rochade repositories.  They felt the help system could become "live" and easily updated that way.  They requested an idea of how they might proceed, 

In general, it is a way to easily integrate the Rochade repository into any existing application.  The possibilities are endless.

The popup screen could have Help Text, but it could just as easily have any other data from the Repository as well!

Here is our response on how to do it:

 
That is a really powerful concept.  Applications have always had a "Help" facility, but the help is usually just static text entered into a pre-built help file.  Here the "help" would be live, and hence always current.

When doing Windows programming (or Java), you can always capture keystroke events.  (Hitting a function key for example would be caught as a keydown/keyup event.)

Below is a thumbnail sketch of how to create a generalized "help" access system to drop into ANY application.  It is  primarily text based, so you merely edit text to change which URLs get fired.  This is very low maintenance.

The .Net framework makes this easy, because now all the languages have the same capabilities.  Your current applications are  currently not .Net.  But if they have an event model, this concept will work easily.

Lets presume you would want to "overload" the F1 (Help) key. You would click in an entry field, and press F1.  The code would catch the F1.  You get the field name from the event. This goes to a single subroutine call that lists screen names and field names with one or more URL's to be fired off.  If there is only one URL, then RoAccess would be started immediately, and would pop up in a new WEB browser window with the information.  If the F1 key was found but it does not have a match in the associated URL file, then the event can be passed on to the normal F1 event handler.

If there are multiple URLs, then a temporary WEB page is generated with the links to each of the URLs and that temporary page is then started in the WEB browser.  You then click the desired URL, and that part is retrieved directly from RoAccess.

Why would there be multiple URLs to go to?
 - definitions
 - validations, range rules, data format, etc.
 - business logic (how it is used and why)
 - other nice to know stuff

I think anyone with C++ or Java experience will immediately understand the concept.  The important thing is not to hard code the URL associations, but put them in a file so a simple text editor can be used, and the file gets read at runtime.

There are a number of variations on this theme.  You can have a "spy" program that monitors what field gets entered and what keys are hit.  This would be used on existing applications that you don't have the source code for.  Such "spy" applications are "screen scrapers" and automated test systems (like Mercury's products).  They know every event that takes place on the screen, and records the information.  You job is easier, because you merely have to look at form name, field name and what key is pressed. The "spy" program then starts RoAccess on the WEB browser using the associated URLs.

The more I think about it, the more interesting the possibilities get.

...Dennis