Client-Server Attribute Design

When widget attributes are explicitly (from 4GL code) or implicitly (as a side effect of some other processing in the runtime) set on the server side, then the GenericWidget.pushWidgetAttr() will be called to save off the change into the synchronization set which will be transferred down to the client and pushed into the client-side widget on the next trip down to the client.

Any processing on the client which causes a change to the widget state will likewise save those changes into the synchronization set which will be transferred back to the server on the next trip up to the server.

This synchronization is handled via piggybacking this state synchronization on our network protocol, creating a kind of "side-channel" to the client. In some cases we will call down immediately from the server to apply the change instead of using the state synchronization mechanism. During frame setup we batch all these up instead of making many trips down.

Of course, all of these changes are really to the internal "config object" of each widget. We don't ever send the widget itself over the wire. We send the part of the configuration which has changes. See *ConfigurationManager classes which manage this.

The state synchronization classes (which act like a kind of plug-in to the low level protocol) can be seen in ServerState, ClientState and the implementation of net/StateSynchronizer by both LogicalTerminal (server side) and ThinClient (client side).

I know of no way that client code would cause a widget to be enabled that isn't already driven by the server. If the 4GL code calls ENABLE, this will go through GenericFrame.enable() which will call LogicalTerminal.enable() which will call down to the client. But the client itself won't spontaneously set a widget to enabled/sensitive.