STM32 - EMWIN widgets (thirteen)

EMWI

foreword

Gadgets are various windows with object-type properties, called controls in the window world, and are the elements that make up the user interface. They can automatically react to certain events, for example, when a button is pressed, it can be displayed in different states. Gadgets need to be created, have properties that can be changed at any time during their lifetime, and are usually deleted when they are no longer needed. Just like a window, a gadget is referenced by the handle returned by its creation function, a gadget requires a window manager, and once a gadget is created, it can be handled like any other window. WM ensures it is displayed correctly (and redrawn) whenever necessary, gadgets are not necessary to write an application or user interface, but they greatly simplify programming

1. Basic knowledge of gadgets

insert image description here
insert image description here
insert image description here
insert image description here

2. How to use gadgets

1. Repainting mechanism

A widget draws itself according to its properties, which is performed when WM_Exec(), GUI_Exec() or GUI_Delay() is called. In a multitasking environment, it is usually a background task to call WM_Exec() and update widgets (and all other windows that have callbacks). When a widget's properties are changed, the widget's window (or part of it) is marked as invalid but not redrawn immediately, so the code snippet executes very quickly. The repaint is performed later by WM, or forced by calling WM_Paint() for the widget (or until WM_Exec() is called when all windows are repainted).

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import warnings
warnings.filterwarnings('ignore')
import  ssl
ssl._create_default_https_context = ssl._create_unverified_context

2. Use of gadgets

Suppose we want to display a progress bar, all we need is the following code:

PROGBAR_Handle hProgBar; (1)
GUI_DispStringAt("Progress bar", 100, 20);
hProgBar = PROGBAR_Create(100, 40, 100, 20, WM_CF_SHOW); (2)

(1), define a progress bar handle.
(2) Call the PROGBAR_Create() function to create a progress bar. After the creation is completed, the window manager will automatically draw this widget when calling the single WM_Exec(). Each type of gadget has several member functions that modify its appearance. Once the gadget is created, its properties can be changed by calling one of its member functions, which use the handle of the gadget as the first argument. To make the above created progress bar show 45% and change the bar color from the default settings (dark/light gray) to green/red, the following code snippet can be used:

PROGBAR_SetBarColor(hProgBar, 0, GUI_GREEN);
PROGBAR_SetBarColor(hProgBar, 1, GUI_RED);
PROGBAR_SetValue(hProgBar, 45);

insert image description here
Default Configurations
All gadgets also have one or more configuration macros that define various default settings (such as the fonts and colors used).

How gadgets communicate
Gadgets are usually created as child windows, the parent window can be any window type, even another gadget, to ensure synchronization, it should usually be notified whenever any event occurs in any child of the parent window Parent window. When an event occurs, the child widget communicates with its parent window by sending the WM_NOTIFY_PARENT message, and the notification code sent as part of the message depends on the event. Most widgets have one or more notification code
skins
that define different types of events. The appearance of widgets can be modified using their respective member functions, some of which support skinning. If skinning is used on a gadget, the "skin" will determine the appearance of the gadget, and some member functions will have no effect.
The use of dynamic memory for gadgets
in embedded applications is usually less desirable due to the splitting effect. Many different strategies can be used to avoid this situation, but as long as the memory area is referenced by pointers in the application, the Use is limited. Therefore, emWin uses a different approach: all objects (and all data stored at runtime) are stored in the memory area referenced by the handle. This enables it to reallocate allocated memory regions at runtime, thus avoiding long-term allocation problems that can occur when using pointers. So all gadgets use handle references.

3. Common control API functions

1. WM functions for controls

Since gadgets are essentially windows, they are compatible with any window manager API routine. The handle of the gadget is used as the hWin parameter, and the gadget is treated like any other window.

WM_DeleteWindow() 删除窗口。
WM_DisableMemdev() 禁止使用存储设备进行重绘。
WM_EnableMemdev() 启用存储设备用于重绘。
WM_InvalidateWindow() 使窗口无效。
WM_Paint() 立即绘制或重绘窗口。

2. Common API functions

<WIDGET>_Callback() 默认回调函数。
<WIDGET>_CreateIndirect() 用于对话框中的自动创建。
<WIDGET>_CreateUser() 使用额外字节作为用户数据创建小工具。
<WIDGET>_GetUserData() 检索用<WIDGET>_SetUserData 设置的数据。
<WIDGET>_SetUserData() 设置小工具的额外数据。
WIDGET_GetDefaultEffect() 返回用于小工具的默认效果。
WIDGET_SetDefaultEffect() 设置用于小工具的默认效果。
WIDGET_SetEffect() 设置用于给定小工具的效果。

Indicates the name of the gadget, of which the function _CreateIndirect() is particularly important, because this function is used to create each gadget when using the dialog box.

3._CreateIndirect()

Description
Creates a widget to be used in a dialog.
function prototype

<WIDGET>_Handle <WIDGET>_CreateIndirect(
const GUI_WIDGET_CREATE_INFO * pCreateInfo,
WM_HWIN hParent,
int x0,
int y0,
WM_CALLBACK * cb);

Additional Information
Any widget can be created indirectly using an appropriate prefix. For example: BUTTON_CreateIndirect() indirectly creates a button widget, CHECKBOX_CreateIndirect() indirectly creates a checkbox widget, and so on. It is only necessary to create a widget indirectly if it is to be included in a dialog, otherwise it can be created directly using the _Create() function.

Guess you like

Origin blog.csdn.net/qq_51963216/article/details/124034681