GUI Testing

KwikPeg provides a prototyping facility for testing an actual KwikPeg graphical user interface (GUI) on a Windows^® workstation. You can create, program and test your GUI before moving to your target hardware. Your GUI will be presented on the Windows screen with exactly the same screen resolution and color depth provided by your target video device driver. The examples provided with KwikPeg have been built using this GUI testing methodology. And using TAPS (The AMX Prototyping System) you can actually test your GUI while running with AMX.

** Important Note **
To test your GUI on a Windows platform, the environment variable PEGPATH must be defined. PEGPATH specifies the full path to your installed copy of PEG.

To test your GUI under Windows using TAPS, the environment variable TAPSPATH must be defined. TAPSPATH specifies the full path to your installed copy of TAPS.

To set environment variables under Windows, use the Environment page of the "System" Control Panel.

To test your GUI using Windows, you will need Microsoft Visual C++ operating in its visual integrated development environment (IDE). You do not need to be a Windows programmer to use this tool to test your KwikPeg GUI.

	Building the KwikPeg Demonstration Library
	Building KwikPeg Examples
	Preparing a GUI for Test
	Testing an Application GUI
	Testing your GUI with TAPS
	Testing with a Target Screen Driver

Building the KwikPeg Demonstration Library

The simplest way to describe the KwikPeg prototyping facility is to illustrate its use in the construction of the GUI examples delivered with KwikPeg. The examples are located in the KwikPeg installation directory KPGnnn\EXAMPLES.

The first step in the GUI testing process is always the construction of a KwikPeg Library using the Microsoft Visual C++ tools. All of the KwikPeg examples use a common KwikPeg Library file KPG_DEMO.LIB which, once built, resides in the KwikPeg installation directory KPGnnn\EXAMPLES\_LIB. You will note that the KwikPeg Library Parameter File KPG_DEMO.UP used to configure the library is located in that directory. The library will automatically be built, if it does not exist, when any of the KwikPeg examples is built.

Although there is no need to do so, you may wish to build the KwikPeg Library used by the examples just to confirm the simplicity of the construction process. Start Visual C++ and open the workspace file EXAMPLES.DSW located in directory KPGnnn\EXAMPLES. Make project _LIB the active project. Select the Build option (via menu, toolbar or keyboard) and Visual C++ will compile all KwikPeg library source files and merge the resulting object files into a KwikPeg Library file named KPG_DEMO.LIB in directory _LIB\DEBUG (or _LIB\RELEASE).

There is one important distinction between this KwikPeg Library and that which you will eventually make for your target application. The KwikPeg demonstration library includes two files not found in any other library. One is the main Windows application which implements the KwikPeg Presentation Manager and provides Windows keyboard, mouse and timing services. The other is a Win32 compatible KwikPeg video device driver used with the GUI examples for screen drawing.

	Top of page

Building KwikPeg Examples

Once the demonstration version of the KwikPeg Library is available, any of the KwikPeg examples can be built. The construction of the simple window example in the BASIC directory will be used to illustrate the process.

From the Visual C++ workspace in directory KPGnnn\EXAMPLES, make project BASIC the active project. Select the Build option (via menu, toolbar or keyboard) and Visual C++ will compile the example source file(s) and merge the resulting object files with the KwikPeg Library file KPG_DEMO.LIB to create an executable Windows application. All of the executable files (those with extension EXE) installed in the EXAMPLES subdirectories were created by KADAK using this technique.

	Top of page

Preparing a GUI for Test

To test your own GUI without AMX (or TAPS), you must implement the GUI so that it has no dependencies on your target hardware or on the AMX kernel. For example, although a button press may have to send an application message to force a task to open a valve or start a motor, there can be no such action initiated when testing your GUI on the Windows platform in a stand-alone fashion.

There are several techniques which you can use to avoid runtime target dependencies. The simplest approach is to omit the target sensitive code from your GUI modules until the GUI has been tested. The disadvantage of this technique is that it is much too easy to forget to add the critical pieces of code in all of the right places.

An alternative is to code the runtime sequences but omit them from the compilation process. The KwikPeg symbol KPP_OS_WIN32 will always be defined and non-zero when your source files are compiled for GUI testing. Runtime dependent code sequences can then be conditionally precluded from compilation as illustrated in the following example.

    #ifndef KPP_OS_WIN32
    OS_message(valve_taskid, OPEN);
    #endif

Another alternative is to provide one or more stub modules which satisfy your GUI linking requirements but have no runtime target dependencies. The stub modules contain all of the functions referenced by the GUI modules but unavailable when testing with Windows.

	Top of page

Testing an Application GUI

The procedure followed to test a stand-alone application GUI is similar to that described for building the KwikPeg examples. However, GUI testing is performed in the KwikPeg installation directory KPGnnn\GUI_TEST. This directory includes two subdirectories, _LIB and APP_TEST. Your KwikPeg Library will be generated in directory _LIB. Your Windows executable program for testing your GUI will be constructed in directory APP_TEST.

** Important Note **
You MUST ensure that environment variable PEGPATH has been defined to specify the full path to your PEG installation directory, say C:\PEG.

Start Visual C++ and open the workspace file GUI_TEST.DSW located in directory KPGnnn\GUI_TEST. If you have not already done so, copy your KwikPeg Library Parameter File (say MY_APP.UP) into directory GUI_TEST\_LIB and rename it to be GUI_TEST.UP. If your configured screen driver does not support Windows testing, use the KwikPeg Configuration Manager to edit your KwikPeg Library Parameter File to use the Win32 screen driver.

Make project _LIB the active project. Select the Build option (via menu, toolbar or keyboard) and Visual C++ will compile all KwikPeg library source files and merge the resulting object files into a KwikPeg Library file named GUI_TEST.LIB in directory _LIB\DEBUG (or _LIB\RELEASE). KwikPeg Library header file KP_LIB.H will also be generated and left in the _LIB directory.

There is an important distinction between library file GUI_TEST.LIB and the version that you will eventually make for your target application. This library includes a main Windows application module which implements the KwikPeg Presentation Manager and provides Windows keyboard, mouse and timing services.

Once your KwikPeg Library has been built, make project APP_TEST the active project. Either copy your GUI header files and source files into directory APP_TEST or revise the project definition to specify the path to them. Add your GUI source files to the list of files to be compiled as part of the project.

Select the Build option (via menu, toolbar or keyboard) and Visual C++ will compile your GUI source file(s) and merge the resulting object files with the KwikPeg Library file GUI_TEST.LIB to create an executable Windows application named APP_TEST.EXE. Of course, you can revise the project definition to give this application a name of your own choosing. Run the application and your GUI will appear exactly as your source code specified, mistakes included.

Knowledgeable Visual C++ programmers will want to revise the project definition to compile the GUI source files with debug information so that execution of the GUI application can be debugged using the Visual C++ debug features inherent in its IDE.

	Top of page

Testing your GUI with TAPS

The procedure followed to test an AMX application GUI using TAPS is similar to that described for testing a stand-alone GUI application. However, GUI testing is performed in the KwikPeg TAPS installation directory KPGnnn\GUI_TAPS. This directory also includes two subdirectories, _LIB and APP_TEST. Your KwikPeg Library will be generated in directory _LIB. Your Windows executable program for testing your GUI with TAPS will be constructed in directory APP_TEST.

** Important Note **
You MUST ensure that environment variable TAPSPATH has been defined to specify the full path to your TAPS installation directory, say C:\KADAK\TAPS302.

Start Visual C++ and open the workspace file GUI_TAPS.DSW located in directory KPGnnn\GUI_TAPS. If you have not already done so, use the KwikPeg Configuration Manager to edit your KwikPeg Library Parameter File (say MY_APP.UP) to use a protected mode 80x86 processor instead of your actual target processor. If your configured screen driver does not support Windows testing, choose the Win32 screen driver instead. Then copy the file into directory GUI_TAPS\_LIB and rename it to be GUI_TAPS.UP.

Make project _LIB the active project. Select the Build option and Visual C++ will create a KwikPeg Library file named GUI_TAPS.LIB in directory _LIB\DEBUG (or _LIB\RELEASE). KwikPeg Library header file KP_LIB.H will also be generated and left in the _LIB directory.

The procedure to be followed to build your GUI application with AMX and TAPS is just like that used to test any AMX application with TAPS. Your AMX system configuration may have to be modified to permit one extra task which will be automatically created at the lowest priority (just above the TAPS Task) when your AMX application runs.

Once your KwikPeg Library has been built and all of your AMX and GUI application modules are ready for testing, make project APP_TEST the active project. Either copy your GUI and AMX application header files and source files into directory APP_TEST or revise the project definition to specify the path to them. Add your source files to the list of files to be compiled as part of the project. Then select the Build option and Visual C++ will build your TAPS application, a Windows executable file named APP_TEST.EXE

The procedure to be followed to test your GUI with AMX and TAPS is just like that used to test any AMX application with TAPS. You can even use the KwikLook Fault Finder provided with TAPS to debug with full AMX task awareness.

	Top of page

Testing with a Target Screen Driver

Your application may have to use a screen driver with a screen resolution and color depth which differs from that provided by the Win32 video device driver which is usually incorporated into the KwikPeg Library for GUI testing.

The KwikPeg examples use only 16 colors. However, some of the images embedded in a few the examples require more than 16 colors for proper display. For this reason, the examples use a 256 color screen. The Win32 screen driver can support up to 256 colors. It will not support more than 256 colors even if your Windows workstation does. It is recommended that you use the Win32 screen driver, even for 2 or 4 color systems, until your GUI is functional.

Once your GUI code is proven, you can replace the Win32 screen driver with the KwikPeg template driver which most closely matches your intended video controller, provided that the driver supports Windows testing. To do so, edit your KwikPeg Library Parameter File to select the screen driver of interest. Add the screen driver header and source files to the _LIB project and remove any other screen driver files which the project might have included. Then rebuild your _LIB project to generate a new KwikPeg Library which incorporates your selected screen driver. For example, you can add the 4-color linear template driver (files L4SCRN.CPP and L4SCRN.HPP) to your KwikPeg Library to simulate the use of a 4-color video controller, even if that controller is not linear.

Many of the KwikPeg template drivers include conditional Win32 support for drawing under Windows for GUI testing. Any of these drivers will render your KwikPeg screen exactly as it will appear on your target display. Hence, when your GUI is moved to the target hardware with a video screen driver derived from the template, display discrepancies will probably be attributable to your custom, controller-dependent code sequences in the modified driver.

	Top of page