Since the configuration of shortcut keys and tip messages is relatively simple, they are introduced together in this article.
First, let's discuss the mechanism by which DYQML implements shortcut keys: shortcut keys are actually a type of user event, just like other user events such as when a mouse clicks a button or selects an option from a dropdown menu. The purpose of these user events is to elicit a response from the interface or the C++ backend program. Therefore, DYQML realizes all these user events by issuing a dSignal and the corresponding response. Consequently, the signals emitted by shortcut events are also generated by the events and correspond to the three signals emitted by the DYQML specification using the signal dispenser. For more details, please refer to sections 2.1 and 2.2 of Signal System Composition. Once you understand the composition of the DYQML signaling system, this concept becomes quite clear.
In simple terms, specify different shortcut keys emitting corresponding dSignal in configuration files. After that, the rest is handled by the DYQML signaling system. The user only needs to respond to the event in the control or background program by responding to the signal.
The shortcut key configuration is located within the top-level entry point appSetting, taking the file Ctrl-Demo-Button-EN.json as an example:
A shortcutList is a JSON array, or ordered list, that can internally consist of one or more shortcut configuration objects. In the above example, the shortcutList contains three objects corresponding to the keyboard keys A, B and C. Pressing these shortcut keys, DYQML will emit a series of signals corresponding to them using the signaling system, and these signals are defined in the dSignalList. In other words, a shortcut key can send out multiple signals instead of only one. For example, the length of the dSignalList for the three shortcuts above is 3, so each of them can emit 3 signals. This is to increase the flexibility of the system to adapt to complex business needs, but it is not recommended to configure too many signals for one shortcut, just configure them according to the business needs. Click to expand the dSignalList to see the specific signal configuration information:
The signal body sent within the system is defined as dSignal. dSignal is a data structure for signal transmission defined in this project, and each dSignal must include at least the sigId information, which is the identifier of the signal. Without it, the signal will not be sent. Here, we do not need to understand too much about the setup of dSignal. It is sufficient to know that if dSignal is used, its signal identifier sigId must be configured, while the destination code destCode and the sub-information subInfo are not mandatory. For more detailed information about the system's signals and the signal system, you can refer to the article Signal system composition.
The program loads three shortcut keys, namely A, B, and C. When A is clicked, it sends out three signals to the QML interface, with the IDs of these signals being short-cut-A-sig1, short-cut-A-sig2, and short-cut-A-sig3 respectively. Clicking B and C will also send out three different signals accordingly.
For comparison, the JSON source code for the above configuration information is as follows:
"appSetting": {
"width": 1280,
"height": 700,
"shortcutList": [
{
"keys": "A",
"dSignalList": [
{
"sigId": "xxxx-xxxx-a1",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-a2",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-a3",
"destCode": "100",
"subInfo": ""
}
]
}, {
"keys": "B",
"dSignalList": [
{
"sigId": "xxxx-xxxx-b1",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-b2",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-b3",
"destCode": "100",
"subInfo": ""
}
]
}, {
"keys": "C",
"dSignalList": [
{
"sigId": "xxxx-xxxx-c1",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-c2",
"destCode": "100",
"subInfo": ""
}, {
"sigId": "xxxx-xxxx-c3",
"destCode": "100",
"subInfo": ""
}
]
}
]
}Tip messages refer to the informational tips that appear when a user hovers their mouse over a control. With DYQML, it is very convenient to add these tips to the interface through the configuration file.
For DYQML, since all controls are inherited from DObject and tipText is a property of DObject, all controls have the ability to generate tip messages. The system implements the tip information by instantiating DYToolTip, and DYQML optimizes the tip information accordingly: 1. Only controls configured with the tipText property may generate a DYToolTip object, otherwise the DYToolTip exists in the state of Component; 2. Only when triggered by a user event, the corresponding DYToolTip object will be generated and dynamically destroyed when the user event ends. This ensures that at a certain moment, there is only one DYToolTip object in the whole system, which is very necessary to optimize system performance in some special cases.
The configuration is very simple, just configure the tipText property and value in any control where you want to add a tip message:
There are only two things to be aware of when using tip messages: 1. Control overrides, where the upper control overrides the lower control, then the tip message of the lower control will not be displayed; 2. Controls with mouse user events may conflict with the mouse event of the tip message.