Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4276797

Making modal dialogs to be not modal without hiding them.


    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 1.2.2
    • Fix Version/s: None
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      Name: krT82822 Date: 09/29/99

      If I show a modal dialog, it blocks until you hide it.
      We need for our applications to unblock the dialog calling,
      for example, dialog.setModal(false), but no hiding it.



      9/10/99 more feedback from user:

       Thank you for your answer.
        I'll try to explain you our problem (and sorry for telling you my live
      and the large message):

        We are migrating to Java (multi-platform language) a large application
      suit (+- 4000 finnancial transactions Host/terminal) that we finnished last
      year. It was developped in CT/2 (an OS2 only IBM tool with support for IBM
      Host communications and finnancial devices via Landp, an more).

        We need to do a technical migration to Java. It means that the Java
      application must have the same Look (skywalker :>) and Feel. We are in the
      way to do this, and with Java it's possible to do even a better application
      than CT/2 (better currency field pictures, performace, etc). Our clients
      want to have the SAME application because they are tired learning the 4000
      transactions. In a seccond step (next years) we will develop a non-CT/2
      like application

        But we have a problem: all the CT/2 windows have the same modal
      behaviour: (in middle CT2 code)

      1. show the first window
      5. activate the first window
      6. 'read' the first window (set to modal state)
        6.1. (in modal state): while (modal_state_is_on && window_is_opened)
        6.2. (in modal state): dispatch messages for dialog (mesagges loop)
        6.3. at the end of the loop, NOT HIDE the window
      9. look for variables and buttons pressed on dialog
      10. If there is a validation error go to point 5
      11. else
          12. show the first window
          13. activate the second window
          14. 'read' the second window (set to modal state)
            14.1. (in modal state): while (modal_state_is_on &&
            14.2. (in modal state): dispatch messages for dialog (mesagges
            14.3. at the end of the loop, NOT HIDE the window
          16. look for variables in second window
          17. If there is a validation error go to point 12
          18. If you pressed PREVIOUS_PAGE, go back to point 5

      (the points: 6.1, 6.2, 6.3 and 14.1, 14.2, 14.3 are CT/2 Native code
      that we don't programm)

        It means that while a dialog is in 'modal state' the other application
      windows are disabled, and the user can't navigate between windows. This is
      very important because the complexity of many transactions with more than 7
      input windows and douzens of possible output windows for the Host
      responses, and validations, special behaviours and links, etc.

        We can use a non-modal window but we won't have the same behaviour: the
      windows are independent between them (the user can click on other windows
      and activate them).

        We tried to do our own modal windows taking a non-modal window and doing
      the message loop that native window managers do, after doing
      setVisible(true). But there are many problems on using the
      SystemEventQueue, because not all events arrive at our EventQueue, we must
      disable EventQueueDispatcher thread to controll all the events and not
      compete with him, but when we do that,
      SwingUtilities$IDontRememberWhatComponent has problems and aplication

        We have searched in jdk .java sources but in the Dialog's show method,
      the method only do peer.show() to do the message loop, and the peer is the
      native IBM JDK for OS/2 Dialog window and I don't have the sources, but I
      think this peer class only do a native call to an javaw.dll entry point.

        Another important problem originated from this is that an non-modal
      window make the executing flow to continue after a setVisible(true). A
      modal window blocks until the user press a button, for example. This is
      very important too for this reason:

        We have started with this project this year 1999, and at the end of the
      year we MUST FINNISH the applications!!!. Four thousand transactions (in
      CT2 it took several years with a tool ready to show windows, host
      communications, etc) an a big arquitecture in ten months: IMPOSSIBLE to do.

         Then we thought in a parallel project at aside to this application:
      simulating an CT/2 interpreter from Java (100MB of CT2 programs + 6000 CT2
      windows + 7000 CT2 record formats will run in Java in ten months!). This is
      a way to end before year finalization. The interpreter is a bypass solution
      for one or two years until the real and truly Java application ends.
        We are at the final state of this little project but we have a problem:
      the CT/2 modal dialogs. The CT2 windows blocks in the program flow at
      points 6 and 14. I'm using non-modal windows to show the components and
      to block the CT2 simulated program flow until I peek a message in the
      queue, but I still can't click on other window and my code don't works

        If the Java Modal Dialogs would work as we request the work will be
      different. You don't think so?. We have lost weeks trying this feature.
      You can see it's very important for us. In the future, possibly all the
      components that we have distributed in four windows we'll put then in the
      same window (like a HTML window) and we don't have problems like that :)

        I know is not a normal request. Possibly none of the One Million of Java
      Developers in the world have ask you for this problem (I have searched with
      your database find engine and I didnt saw anything like this).

        Thanks and congratulations if you have reached this point of the message.
      You seem to have good nervs.

        Sorry for my english.
        Have a good day.


      9/29/99 eval1127@eng -- user would like RFE noted.
      (Review ID: 95071)


          Issue Links



              • Assignee:
                rraysunw Richard Ray (Inactive)
                kryansunw Kevin Ryan (Inactive)
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: