AE JUI Explorer window steals keyboard focus after OFS kick

[Michael A. Lowry]

I’ve been developing a new workflow in the past few weeks, and have been stymied by a repeated problem: while typing into the Process tab of an object, the window would suddenly stop accepting keystrokes. Instead, although the workflow editor window still appeared to be in the foreground, the keystrokes were going to an AE Explorer window in the background. This caused a near disaster at one point when I typed the Delete key, expecting to delete a few characters from what I had just typed, but instead the key was interpreted as a request to remove several objects that were selected in the background Explorer window. If I had not been paying attention, or had typed the Enter key at this point without seeing the confirmation dialog box, these objects would have been deleted.

 

I enabled tracing to see what was going on, and was able to capture traces during several instances of the problem. Here is what seems to be happening:

1. Whenever anyone makes any change to the AE client folder tree (creation, deletion, or name change of any folder), the AE sends out an OFS kick to all connected Java User Interfaces. This instructs these connected programs to refresh their folder tree cache.
   

   20181122/142208.236 - U04006705 Receive XML:<uc-env session="">
     <kick client="0405" idnr="0000000000" system="AE_DEV">OFS        </kick>
   </uc-env>

2. Upon receipt of an OFS kick, the Java User Interface requests & receives the updated folder tree.
   

   20181122/142211.564 - U04006705 Receive XML: AE_DEV_405
   <uc-env redlight="0" request="ofs_155" session="0000000178867273" useridnr="0001107131">
     <tree selectedId="3976108" src="ofs">
       <node id="1107001" name="UC4_DEV - 0100" parent="" type="CLNT"/>
       <node id="0" name="&lt;No Folder&gt;" parent="1107001" type="NFOLD"/>
       <node id="4" name="Favorites" parent="1107001" type="FAV"/>
   
       ... approx. 12,500 nodes ...
   
       <node id="3712518" name="TEST4" parent="3722047" title="" type="FOLD"/>
       <node id="3715335" name="TEST5" parent="3712518" title="" type="FOLD"/>
     </tree>
   </uc-env>

3. As soon as this tree has been completely received, the Java User Interface refreshes any open Explorer windows to show the newly updated tree. This is when the problem happens. The refresh of the Explorer windows apparently causes them to invisibly steal focus from any windows in the foreground. Again, the Explorer windows do not jump to the front. One of them simply begins receiving all of the input entered from the keyboard.

 

I am fairly certain this won’t be fixed, because now that the AWI* is CA’s chosen direction, CA is extremely averse to devoting resources to fix JUI bugs. However, I at least wanted to document the problem, in case others might encounter it.

 

* The AWI works differently. The back-end AWI server is subject to the same OFS kicks, but these do not directly impact the AWI client running in the web browser. Instead, the AWI server provides subsets of the folder tree to the AWI client as needed.

[Keld Mollnitz]

Hi Michael_Lowry,

 

I feel the pain and for what it's worth, we are in the same situation as you and I have also had several "close calls", that could have caused un-intended deletion of objects.

Except from that, it is quite annoying when you are typing ahead and then sudennly find out that the window you thought was the active one did not accept the input from your keyboard...

 

/Keld.

[Michael A. Lowry]

I did a few more tests and confirmed how the folder tree in the Java User Interface is impacted by OFS kicks. If multiple folders in the tree are expanded in an Explorer window when an OFS kick is received, then after the folder tree has been refreshed, only the currently-selected folder will remain expanded. All others will be collapsed.

 

See also:

Forced GUI refresh and AE kick events 

AE kicks