The GUI library is to a large extend compatible to the GUI interpreter of our LCM2 modules. Therefore applications which have been developed for a LCM2 module can be easily ported to a GUI library application for a customer specific target hardware.

The LCM2 modules are controlled by the application hardware by sending instructions. Thus, at first sight, they are quite different from applications which were developed with the GUI library. For the purpose of application development this difference can be "hidden" which makes the source text quite similar.

A summary is given by the following table:

Application for the GUI library	Application for LCM2 modules
Display instructions are directly compiled for and executed on the custom specific hardware	Display instructions are sent as data packets from the controlling customer hardware to the LCM2 module where they are executed by the GUI Interpreter. The communication follows a "master-slave" scheme. The customer hardware controls the whole application and thus is the "master", the LCM2 just executes the instruction and therefore is the "slave".
In order to execute a display instruction in the application one directly uses one of the numerous instructions of the GUI library, e.g. the function "disp_text" (display of text).	To execute a display instruction within an application the respective data packet needs to be generated and sent to the LCM module. For generating these data packets our customers are provided with a library (the GUI-Master-LIB, written in ANSI-C, which comes as a part of the starterkits). This library provides functions analogue to those of the GUI library, e. g. a function "disp_text" (display of text).
Example for the call of a GUI library function: disp_text("Hallo World");	Example for the call of a function to control the LCM2 display terminal module: disp_text("Hallo World");
Internal procedure: The function disp_text renders the graphical pixels according to the text output and controls the LCD controller used on the customer hardware.	Internal procedure: The function disp_text assembles a suitable data packet and sends it to the LCM2 module.
Result: "Hallo World" is shown on the display. The call is the same like the one when controlling a LCM2 module.	Result: "Hallo World" is shown on the display. The call is the same like the one when using the GUI library on a customer hardware.

The important question about the degree of compatibility can be answered as follows:
There are some differences and thus just "compile for the other kind of application" does not work.

However, there are only a few modifications needed for migration and they are well localized within the code. The logic of how the display functions are used is not affected. These modifications can be done without consuming too much time (usually by "search and replace").

The following table shows where there is a difference and how migration is done:

Case	Difference GUI library Interfacing a LCM2 module	Work for migration
Initialising	The GUI library must initialize the customer hardware. This is different from initialising the communication to the LCM2 module.	The respective initialising sequences must be replaced.
Special instructions for controlling the hardware, e.g. for adjusting the brightness of the display.	For the GUI library function stubs are provided and need to be filled with code according to the hardware used.. For the LCM2 modules the functions are implemented completely and can directly be called.	For a custom specific hardware using the GUI library functions for controlling the hardware have to be implemented.
Functions with text output on the display or with numbers as parameters (e.g. disp_text). Most of the functions are of this type.	Functions look the same and also have the same function prototype (Example.: err_code disp_text(char* dertext);	None (this is the case most of the time).
Statical Objects: Graphics Touch keyboards Additional fonts Fill patterns Text for special purposes which is not directly shown with "disp_text", e.g. button labels	In applications with the GUI library object data is inserted into the source text. The objects are then represented by pointers to this data. For an application for LCM2 modules these objects are directly "uploaded" into the LCM2. The objects are then represented by an "object ID".	Statical objects, which are accessed by a LCM2 application, need to be transferred into the LCM2 (to flash memory or RAM). For a typical application this needs only to be done for a very limited number of objects. Often the "Upload" can be done with simple functions at the beginning of the application, so modifications do not need to take place somewhere else.
Functions, which have an "object" as a parameter. Example: A bitmap picture shall be shown using the function disp_bmp. The call is in both cases: disp_bmp(testpicture);	In the GUI library the data, e. g. the picture data, are directly accessed via a pointer. For an application with the LCM2 the object ID of the object is passed and transmitted to the LCM2. While the call of the function looks the same, the parameters which denote the objects for the GUI library are of the type of the object and for the LCM2 application they are of the generic type "TObjectID"	The data types representing an object are different and must be changed at the declaration of the variable (this happens at just one place, typically at the beginning of the function). The call of the functions which use the object, does not change.

Summary:

The work to be done for migration is quite limited and mostly consists of the implementation of functions which need to be implemented anyway, for a custom specific hardware (initialisation, control of power supplys for display backlight or contrast).

The modifications remaining consist of replacing declarations which can be easily done at the start of functions ("search and replace").