A grayed-out interface button is not enough to show that a physical membrane key has been disabled. For an ordinary control using passive contacts, a gray appearance does not mean the contacts have opened. Check the widget state, the path from physical input to function-request acceptance, and the handling of requests already present during the disabled period. The equipment project should define the expected behavior first, then verify it against input and request records. This article covers non-safety functions such as menus and information browsing, not warning acknowledgment, emergency stops, interlocks or motion permission.
In its November 1, 2026 report on an integrated-unit delivery, Xinhua described hardware already in place for the MAZU project in Sri Lanka, with the customized system still under development and business operation expected by the end of 2026. Hardware delivery and system operation are different stages; a planned start must not be described as an accomplished one.
If your own project also continues software integration after hardware arrives, and separately includes physical membrane keys, add an ordinary-operation check: which input paths can still create a request when the interface is unavailable? The connection here is phased integration. It does not imply that the reported equipment uses membrane switches, has a disabling problem or is supplied by Baoshengda, and it does not address that project's weather-warning logic.
Identify where disabling takes effect
List the gray appearance, the software widget's enabled state and the conditions for accepting a function request separately. Changing text or background color alone does not establish that input is blocked. Even when a widget is disabled, check whether the physical key actually passes through that widget or instead uses a separate board input or application callback.
The Qt QWidget enabled-property documentation describes input handling and possible gray appearance separately, and notes an exception for QAbstractButton. Check the actual widget and project connection rather than treating the general description as a rule for every button and input path. This documentation concerns Qt widgets; it does not establish that a device uses Qt or that an external contact-input path has been disabled.
The LVGL 9.3 widget-basics documentation lists the disabled state under States and the clickable flag under Flags, with an example of removing the clickable flag. Record which object, state or flag is changed. The software owner still needs to check the actual calls and input driver; these interfaces are not assembled here into a ready-to-use disabling program.
Compare input paths for the same ordinary menu function
The following is a suggested integration record, not a universal acceptance standard or a test result for the news project. Choose a menu-browsing function that does not drive equipment actions. In a project-approved simulator or isolated bench setup, define which input paths should be rejected and which may remain available before comparing them. Do not bypass interlocks, alter running equipment controls or create hazardous conditions to test disabling.
| Comparison condition | Records to retain together | Question to resolve |
|---|---|---|
| Only the color changes | Screen, target-widget state, input path and request records | Did only the appearance change, or also the enabled state? A screenshot cannot supply an unobserved input conclusion. |
| The touch widget is disabled | Widget identity, configuration or call, touch operation and function-acceptance result | Does this check cover that widget, or has it incorrectly been reported as disabling every physical input? |
| The physical membrane key for the same function is pressed | Key and input identifiers, input state, request creation and acceptance result | Does the input pass through that widget or enter another application path? At which layer does the project require rejection? |
| A request exists before entry into the disabled state | When disabling takes effect, the original request identity and its subsequent handling | Do rejection of new requests and treatment of existing ones each follow the specification? Erasing an execution record is not cancellation. |
| Operation is enabled again | Recovery conditions, current input state and the distinction between new operations and old requests | Which operations become valid again, and is release followed by a new press or confirmation required? Check the project rule rather than assuming a universal default. |
For your own phased hardware-and-software project described above, keep any layer without usable request-creation or acceptance records pending verification. A temporary interface that turns gray and a panel that passes a separate continuity check establish only their respective observed states. They cannot be combined into proof that disabling has passed at equipment level.
A changing contact does not necessarily mean disabling failed
Pressing a passive-contact key may still change its physical contact state. If the project defines disabling as the application refusing a function request, check whether the request was created, whether it was accepted and what happened on the actual interface. Software graying does not have to alter the switch's internal structure. Conversely, an unresponsive touchscreen does not prove that a physical key on an independent path receives the same treatment.
Keep conclusions at the layer supported by the record. An input that is recognized but whose function is rejected differs from an input that never arrives. If intermediate records are missing, gather evidence to locate the issue before declaring the panel faulty. For indicator meanings, see key, action and status-indication consistency (Chinese). For fixed legends after a software revision, see HMI-upgrade legend and function checks (Chinese). Neither replaces request-acceptance checks for disabled input paths.
Hand over component data and disabling rules separately
The membrane-switch customization information from Shenzhen Baoshengda Technology Co., Ltd. (Chinese) calls for key definitions and circuit or interface data, with mapping, continuity and installed behavior checked using matching housing and board revisions. An English product overview is also available. Panel data can identify which key corresponds to which input. The responsible equipment parties should confirm software widgets, independent input paths, disabling and recovery rules. This public information does not establish that Baoshengda provides arbitrary interface programs, access controls or equipment-level disabling verification services.
When using the project contact page, associate key and pin assignments and panel and board revisions with the approved definition of when an ordinary function is available or unavailable. List unfinished software-layer records separately rather than treating component sample approval as covering them all. A membrane panel or graphic overlay without switch circuitry is not a complete membrane switch. For an overlay with metal domes used with the customer's PCB, list the PCB and readout circuit separately.
The cover shows only the window, number keys, function legends and tail of an existing blue sample on this site. It is neither the news equipment nor a screenshot from this integration exercise, and it cannot establish a software framework, disabling function or test result. Base acceptance conclusions on actual revisions, input paths and request-acceptance records; leave uncovered paths pending verification.