Introduction In the current mid-to-low-end PDAs, many manufacturers use Motorola M68K series chips. Motorola provides a free real-time operating system PPSM (Personal Portable System Manager) for its M68K CPU. However, the system does not provide a window system. In practice, we developed a window system, as shown in Figure 1 and Figure 2. The system is event-driven and has a series of controls. Software developers build the required windows by adding controls and write the response methods for controls and window events. The design scheme of this window system is introduced below. 1 Introduction to PPSM System (1) Virtual Multitasking Mode Multiple main tasks can be created in the PPSM system, but only one main task is active. Each main task can create multiple subtasks. Both the main task and the subtasks have a unique TaskId. Messages can be sent between tasks. The task that receives the message and its main task can obtain control of the CPU. (2) Touchscreen Input The PPSM system adopts the concept of "active area". The "active area" is a rectangular area on the screen set by the user. Only the movement of the pen in such an area can cause PPSM to send a message to the active task. Each active area belongs to the task it created. In other words, each task saves and manages a series of active areas. The active areas of all subtasks of the main active task are active, and the active areas created later overwrite those created earlier. (3) The graphical interface supports PPSM system using a portion of system memory as a screen cache. Each task can have its own independent screen cache or share a screen cache. The size of the screen cache can be different from the actual screen size. The system displays the image in the screen cache of the active task. Each main task has its own independent screen cache, which can quickly switch screens when switching main tasks; while sharing a screen cache among main tasks can save memory space. At the same time, the application can also create screen caches independent of the task. It has the same structure as the screen cache, but cannot be directly output to the screen. Users can set the current screen cache. PPSM provides a set of GUI functions for drawing in the current screen cache. (4) Event-driven PPSM uses interrupts to handle various events, such as clock, UART input/output, pen input, etc. All events send messages to the active task. Each task (main task or subtask) has its own message queue. Each task retrieves and processes messages from its message queue. Since PPSM uses an active area input method, each task manages its own active area, which is active when the task is active. Therefore, when the application switches, its active area switches automatically; however, within an application, the active areas of different windows may interfere with each other. Each window in an application has various input areas, and the active areas of different windows may overlap. When displaying a parent window, all active areas of the next window must be invalidated. There are two ways to achieve this. The first way is to use the subtask method in PPSM: each subtask manages its own active area, and its active area is suspended or activated when the subtask is suspended or activated. This requires one subtask per window. Since each new subtask requires a large amount of system memory, and we do not need to switch between windows within the application, we do not use this method. The second way is to use the method of suspending and resuming the active area in PPSM. PPSM supports suspending and resuming the active area multiple times for each task, so we can suspend the original active area when displaying a new window and resume it when the window is closed. (5) Message processing PPSM defines a system of hardware interrupt-generated messages, such as IRPT_TIMER, IRPT_RTC, IRPT_UART, etc.; at the same time, it provides SendMessage and AdvSendMessage functions to allow sending user-defined messages. User-defined messages start from IRPT_USER. A program can send them to another application or itself. These messages and all system messages are handled by the application's top-level window. After the application retrieves a message from its message queue, it first processes common messages by the predefined application message handling function. Then, it processes messages by the message handling function defined for the top-level window. Messages that the top-level window does not handle are handled by the predefined window message handling function. There are two ways to send messages. The first is SendMessage(), which puts the message in the application's message queue and returns immediately; the second is to directly call the application's top-level window message handling function, so that the function returns after message processing. (6) The control system window only provides the foundation for interface design operations. The window needs a series of visual interface elements classified by function and operation method so that programmers can easily design the window interface and implement the specific functions of the window. Such interface elements are called controls. Due to the limited memory of embedded devices, controls do not use the sub-window method. According to the purpose of designing controls, various controls have relatively definite appearance and prescribed actions, and under specific conditions, send predefined messages to their parent window for processing. Controls belong to the parent window. They are automatically displayed when the parent window is displayed and automatically release the memory space they occupy when the parent window is closed; the messages received by the parent window are first distributed and processed in each control. According to this requirement, the window must save and maintain a list of its controls. The pointers of controls in the list are stored in the order in which the controls are created. Controls are displayed in the order of creation, while messages are passed in reverse order in the controls to ensure that the graphics and operations of the controls created later can be overridden by the controls created earlier. In order to improve the efficiency of control development, we need each control to be able to be a sub-control of a newly defined control. In this way, the newly defined control can utilize the functions of the existing control. For example, a text box control can contain horizontal and vertical scroll bar sub-controls. Controls can be divided into those with focus and those without focus. Controls with focus can handle character messages sent by the input method. 2. Implementation of the Window System 2.1 Window Operation Structure Based on the overall considerations of the window system above, the window operation structure requires the following: ① Window position, size, and title. ② Window style: WS_MAINWND—Application main window. Closing the main window will automatically close the application. WS_POPUP—Pop-up window. Clicking a non-window area will automatically close the window. This attribute cannot appear simultaneously with WS_MAINWND. WS_NOBORDER—Borderless window. WS_NOSTATEBAR—Window without a status bar control. Most windows have a status bar at the bottom, providing functions such as popping up a command menu, displaying the window title, closing the window, selecting an input method, and displaying the system date and time. ③ The screen active area and window active area IDs for WS_POPUP type windows. ④ The current cursor position of the window. ⑤ A list of controls in the window. ⑥ A memory pointer to the area the window covers. ⑦ Pointer to the previous window. Used to reset the top-level window of the application when the window is closed. ⑧ Default input method type of the window and handle of the open input method control. ⑨ Handle of the focus control of the window. The focus control will process the character input message first. ⑩ Pointer to the message handling function of the window. 3 Basic tasks of the window and overall considerations of the interface system Since PPSM provides flexible screen caching operation mode, the developed system may conflict due to different screen caching methods adopted by each application and is difficult to coordinate. We developed the window system on the PPSM system in order to make the application interface development easier and faster, so that programmers can focus on the function of the application itself and improve the efficiency and reliability of development. (1) Considerations on interface drawing, switching and restoration Since the target of this window system is a portable device based on Motorola EZ/VZ328, its characteristics are small memory, small LCD screen, slow CPU speed and screen refresh speed; while the window system requires fast refresh speed and small memory occupation. Analyzing the system's characteristics, on smaller LCD screens, switching between child windows is rarely required; therefore, in this window system, child windows cannot be switched. In other words, all child windows are modal; only by closing the parent child window can the next layer of windows be displayed. The portion of a next layer window covered by a parent child window can be saved and restored by the parent child window, or redrawn by the next layer window itself. While the former method saves memory, it is slower, and if only one window is covered by the top-level window, each window must be redrawn sequentially. This is unacceptable on slower CPUs; therefore, we adopted the latter method of saving and restoring the window's covered area. An application (main task) has one main window. Switching between main windows is equivalent to switching applications. If a main window is restored by redrawing, it means that the main window along with all its child windows must be redrawn sequentially, resulting in insufficient refresh speed. PPSM provides the capability that if the main task has its own screen buffer, the screen automatically switches during task switching. Therefore, we adopted this method. Applications have their own screen cache, and each window is drawn on the cache. Each application saves its own window graphics for one screen, which is automatically restored when switching. Since messages are only processed by the top-level window, there is no problem of drawing the interface of the lower-level window in our window system; at the same time, on a small screen, it is not very practical to implement window movement and scaling, so we do not implement these functions of the window. There is another special type of window, namely the window with the POPUP attribute. This type of window is mainly used for menus and prompt windows. Its characteristic is that clicking on the area outside the window will automatically close the window. Our solution is to set a full-screen active area when this type of window is displayed to obtain pen input in the area outside the window; and then set an active area of ​​the window area to cover the active area of ​​the full screen to exclude the window area from the area that is automatically closed when clicked. (2) Considerations on interface input ① HWND CreateWindow(WNDCLASS &wndCls); The WNDCLASS structure defines the basic attributes of the window, such as position, size, title, style, etc., as described above. This function allocates memory for the window's runtime structure, initializes the attributes, and returns a pointer to the window structure. ② BOOL ShowWindow(HWND hWnd); Displays a window. Its tasks include: suspending the previous active area; saving the graphics of the window's overlay area; if the window has the WS_POPUP attribute, setting the active areas of the screen and the window; passing the WM_ONSHOW message to the window's message handling function (actually, directly calling the function) to provide programmers with the opportunity to draw graphics other than controls on the window; if the window does not have WS_NOSTATEBAR, adding a Statebar control; calling the drawing functions of each control in the window in sequence to display the controls; setting the first control with focus as the current focus control of the window. ③ BOOL CloseWindow(HWND hWnd); Closes a window. Its tasks include: sending a WM_CLOSE message to the event handler function of the window; if it returns FALSE, exiting the function; if it returns TRUE, continuing with the following tasks: restoring the window's overlay graphics; releasing the screen active area and window active area of ​​the POPUP type window; releasing the controls contained in the window in sequence; hiding the cursor; releasing the memory occupied by the window structure; sending a WM_TOPWNDCLOSE message to the upper-level window, which is used for the lower-level window to update the interface that needs to change automatically, such as a real-time stock market data table; and setting the window preceding this window as the top-level window of the application. ④ `WNDPROC` function pointer typedef `BOOL (*WNDEVENTHANDLE)(HWND hWnd, U16 msgType, U32 id, P_U32 data, U32 size);` ⑤ `DefWndProc(HWND hWnd, U16 msgType, U32 id, P_U32 data, U32 size);` Handles messages and behaviors such as automatically closing the window when clicked outside the popup window area. ⑥ `U32 WndAddCommand(HWND hWnd, P_S8 cmdName, U16 cmdLen, P_U8 cmdIcon);` Adds an application-defined command to a window with a status bar control. The command appears in the status bar's pop-up menu. This function returns a unique command ID used to distinguish commands when the window handles WM_COMMAND messages. ⑦ `BOOL WndDelCommand(HWND hWnd, HCMD cmdId);` Deletes a command. ⑧ U32 WndSetCommand(HWND, U32 cmdId, P_S8 newCaption); Modify a command. ⑨ Other functions. Due to space limitations, not all window operation functions can be fully listed and explained. 3.1 Implementation of controls (1) Basic structure of controls We use the basic structure of controls to define the common properties of various controls. The specific control structure is extended on this basis to include other properties. The basic properties of controls are discussed below. First, during the display of the window, the appearance of each control is drawn by itself, so each control needs a drawing function. This function is defined when defining a specific control, and a pointer to this type of function is stored in the control structure. Second, each control needs its own message handling function, and the pointer to this function is also stored in the structure. Finally, some controls may dynamically allocate memory space to store their own data. Controls need to release such memory when they are released, so the control structure also stores a pointer to the control release function. A control is an operable area on the window, mainly operated by pen input, so the control needs an active area that responds to pen operations. The number of active areas varies among different controls, so a list of growing active areas needs to be stored in the control structure. However, the screen area of ​​a control may cover other active areas (such as other controls) in some windows, causing confusion in control operations. Therefore, an active area occupied by a control is needed to shield other active areas that may cause interference. Since we need various controls to be used when defining new controls, that is, as child controls of new controls, a list of child controls must be stored in the control structure. The drawing, message handling, and release functions of various controls must be the corresponding default handling functions defined by the control system. These default handling functions call the corresponding functions of the child controls first, based on the list of child controls of the control. (2) Methods for defining specific controls ① A specific control corresponds to a specific structure. The structure first contains the basic structure of the control, and then defines other properties required by the control. For example, a button control needs to have properties such as the type of button, the text or graphic to be displayed, the active area ID required for pen operation, and the pressed state. ② Define the drawing, message handling, and release functions of the control. ③ Define the creation function of the control, such as CreateButton(). The parameters of this function include the initial properties required by the control. The standard part of the parameters is the position and size of the control. This function initializes the properties of the control structure, including initializing the control drawing, message handling and release function pointers in the basic control structure, so that they point to the corresponding functions. ④ Define other functions required for operating the control and accessing the data in the control. (3) System predefined controls In the system, some commonly used controls have been defined using this definition method. They are: ① Button: Text or graphic button, check mode button. ② Label: Label. ③ Checkbox: CheckBox. ④ Radiobox: RadioBox. ⑤ Combo box: ComboBox. ⑥ Scrollbar: ScrollBar: Horizontal or vertical, simple type scrollbars can be used as Spin. ⑦ TextBox: TextBox: Single or multiple lines, editable or non-editable, with selection function. ⑧ Listbox: ListBox: ListBox: Single or multiple columns, options can have icons. ⑨ Statebar: StateBar. It includes a command menu pop-up button, a window close button (displaying the window title on the close button), an input method button, an input method selection button, and a date and time display area. Calendar control: Canlendar. Displays dates for any month and year, with the ability to switch between Gregorian and Lunar calendars. Combination calendar control: Date. Displays dates in a single row and has a pop-up calendar button. Spreadsheet: Excel. Displays database records and can be sorted by the corresponding field in each column. Group control: Group. Used for grouping controls. 3.2 Menu System The menu is implemented by adding ListBox controls to the POPUP window. The menu window's message handling function automatically closes after the user selects an item from the listbox and sends a WM_MENUCLICK message to the application. This message contains the option's sequence number.