FWD » Core Development » User Interface

The logging is now checked into the trunk at revision 10940. The latest run of the program abends with this:

Caused by: java.lang.IllegalStateException: Can not change window to 1 if batch is already started!
        at com.goldencode.p2j.ui.client.gui.driver.AbstractGuiDriver.selectWindow(AbstractGuiDriver.java:1514)
        at com.goldencode.p2j.ui.client.gui.driver.AbstractGuiDriver.enableEvents(AbstractGuiDriver.java:1840)
        at com.goldencode.p2j.ui.client.gui.driver.GuiOutputManager.enableOSEvents(GuiOutputManager.java:257)
        at com.goldencode.p2j.ui.chui.ThinClient.getChanges(ThinClient.java:11882)
        at com.goldencode.p2j.net.Protocol.attachChanges(Protocol.java:274)
        at com.goldencode.p2j.net.Queue.enqueueOutbound(Queue.java:810)
        at com.goldencode.p2j.net.Queue.transactImpl(Queue.java:1109)
        at com.goldencode.p2j.net.Queue.transact(Queue.java:585)
        at com.goldencode.p2j.net.BaseSession.transact(BaseSession.java:223)
        at com.goldencode.p2j.net.HighLevelObject.transact(HighLevelObject.java:163)
        at com.goldencode.p2j.net.RemoteObject$RemoteAccess.invokeCore(RemoteObject.java:1425)
        at com.goldencode.p2j.net.InvocationStub.invoke(InvocationStub.java:97)
        ... 71 more

Here is where we generate the exception (AbstractGuiImpl line 1508):

   public void selectWindow(int windowId)
   {
      if (ews == null || ews.getWindowId() != windowId)
      {
         if (ews != null && batch.peek())
         {
            throw new IllegalStateException(
               "Can not change window to " + windowId + " if batch is already started!");
         }

         direct.selectWindow(windowId);

         ews = direct.getWindowEmulator();
      }
   }   

This code is written such that window selection cannot be done while inside a batch. This concept seems sensible since all drawing ops should relate to the same window.

The problem occurs due to this code (AbstractGuiDriver line 1839, inside enableEvents()):

      // TODO: do we really need to select each window or can we just use
      //       direct.getWindowEmulator() to get each one?  
      for (int wid : windowIds)
      {
         selectWindow(wid);

         ews.enableEvents(capture);
      }

This code can never be used inside a batch. Is it time to address the TODO as a solution? If so, we also need to highlight this batch limitation in some comments so that people don't re-introduce this later.

In our case, the code is being invoked at the end of ThinClient.getChanges(), which seems to be a valid use case:

      // TODO: Disabling OS events here disables all user input on the client (while
      //       the control is on the server). This is in contrast with the original 4GL/Windows
      //       behavior where some input is processed. For example client window can be moved
      //       while the 4GL app doesn't process any user input instructions. 
      tk.enableOSEvents(WindowManager.windowIds(), false);

I guess the other question is whether it is valid to have batch still be active while returning control to the server?

Greg Shah wrote:

I guess the other question is whether it is valid to have batch still be active while returning control to the server?

Batch should never remain open after drawing is completed. I think the exception you've seen is a side effect of something else.

The P2J code fails during this invocation during drawing, as it interrogates the server-side to determine the UI theme - to me it was looking suspicious that ThinClient.getChanges gets called during drawing, but this is a valid case.

   public String getUiTheme()
   {                                                                   
      // first call, request server for current theme to use
      if (theme == null)
      {
         Directory dir = DirectoryManager.getInstance();

         theme = dir.getString(Directory.ID_RELATIVE, "windows-os-ui-theme", "classic")
                    .toLowerCase();
      }

      return theme;
   }

So, the real problem is in AbstractGuiDriver.enableEvents() - changing the loop to this (addressing the TODO) solves the abend:

      for (int wid : windowIds)
      {
         direct.getWindowEmulator(wid).enableEvents(capture);
      }

Thank you. I'll include that change and some related comments in my next check-in.