Addition of Handshake to Display Protocol

Addition of Handshake to Display Protocol

Recently I changed the display widgets / windows controls to be disabled in the Definition File (DF) so disabled when the default forms are initially displayed.  Then, when the connection between the user app and the display app occurs, the user app enables the form and hence any controls that were enabled in the Definition File. 

The DF was changed so that widgets/controls that only need the user app that interfaces with the display layer remained initially enabled so that as soon as the parent form was enabled these widgets became active and usable.  However, widgets/controls that had user code that required communication with another user app to fully determine the command to be transmitted to the display were disabled in the DF.  Then, a command to enable them was sent when the user app to user app connection was established.

With these changes, the controls couldn't clicked, etc until the user application(s) could treat the event.

At times, after these changes were made, the form would never be enabled or the widgets that required connection another user app would never be enabled.  This seemed to occur, although perhaps not in every instance, when the form was hidden under the other form.

I have not discovered whether the display layer failed to receive the command or whether Windows failed to change the status of the control or whether Windows changed the status of the control but failed to update the displayed form and its widgets.  Therefore, I have been adding a handshake to the Display Protocol for communication between a user app and its display app layer.

In the display app, when the command has been received and acted upon to update the display, an acknowledge "event" is sent to the sender of the command with the sequence number of the received extended header as data to identify the received command.

In the user app, each command that is to be transmitted is added to a list of sent commands along with the current value of a timeout counter.  Each acknowledge that is received removes the command with the corresponding sequence number from the sent commands list.  A periodic timeout subcomponent was added to the framework remote component to increment the timeout counter in a thread safe manner.  (That is, the periodic timeout thread only updates the timer and then sends an event to wakeup the remote component main thread.  All other processing is down in the remote component main thread so that the two threads are not both using the same data except for the main thread making a copy of the current value of the timeout counter.)

When the remote main thread receives notification that the timeout counter has been updated, it checks the sent command list for old entries.  Any such entries have their sequence number updated to the next value along with the current timeout counter and the command message is resent to the display.  This should take care of any problems due to the display app missing the command.

In case Windows fails to change the enabled status of a form or widget under some circumstances, I will next modify the display app to check that the Windows interface reports the same status for a control after the display app attempted to change it as the command message specified.  Only if all the widgets specified in the command have their updated status will the acknowledge "event" message be sent to the user application.  Therefore, if Windows doesn't report back the new status the user app will resend the command.

After this second change, if the display ever doesn't match the commanded state then I think the problem would be that Windows updated the state but failed to update the displayed form.