0

I have a GUI which consists of a toolbar with each button invoking different classes. The class I invoke consist of UI components which are displayed in the Internal frame of the main GUI. The Invoked class works as a separate thread and has to perform the following functions.

  1. Trigger a command to the client, so that the client starts sending the contents of a file.
  2. Receive the file contents here,filter it and add it to a JTable.
  3. Progress bar has to be displayed during the file contents transfer.
  4. Display the UI after adding it to the table.

I am new to Swing worker, so can some one help me to get how it works with my situation and the advantages of using Swing Worker and Invoke later function. I followed the examples in the oracle site and few other sites but I am not able to see how this works for my classes.

Joker
  • 81
  • 12

1 Answers1

1

SwingWorker has...

  • Progress change functionality built in, via the PropertyChange support
  • Has helper methods that allow you to synchronise updates to the UI via the publish and process methods, making the process significantly easier...
  • A self contained workflow concept which makes it (generally) easier to use than rolling your own. There are exceptions to the rule, but your outline doesn't fit those exceptions (IMHO) - this is both and advantage and disadvantage...

For example...

One of the (possible) drawbacks to SwingWorker is it will only allow (I believe) 10 workers to be executed simultanously

Community
  • 1
  • 1
MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • The worker thread limit applies when you invoke `execute()` on a `SwingWorker` which will use an internal `ExecutorService`. However, you can `submit` the `SwingWorker` to an arbitrary `ExecutorService` not having such a limit, alternatively. This possibility is documented, hence not just a side-effect. – Holger Apr 10 '14 at 09:05
  • @MadProgrammer Thanks for your reply. I saw your replies. My problem is, I don't get any mistakes while updating the table. It works fine but when I run progress bar as a separate frame, it isn't shown. Only the frame outline is shown that too is in opaque state. Its like of some kind of glass pane that appears instead of the frame. – Joker Apr 10 '14 at 09:40
  • @Holger I haven't used executor service upto now, so I not able to get your point. Anyways thanks for the reply. – Joker Apr 10 '14 at 09:42
  • @Holger Agreed, that could be filled out a bit more, knowing that you can only `execute` 10 `SwingWorker`s in this fashion is sometimes important – MadProgrammer Apr 10 '14 at 09:45
  • @Parthe I'd need to be able to see more details about the frame. Sounds like something is blocking it... – MadProgrammer Apr 10 '14 at 09:45
  • @MadProgrammer Currently my class structure is like send trigger to client in constructor,create UI in one function and then receive contents and update table and then show UI with another function. Is this OK or do I need to improve upon my coding structure. – Joker Apr 10 '14 at 09:48
  • @MadProgrammer The main UI is a frame with toolbar and desktop pane to display internal frame. The components of the Internal frame for different classes are a table and 2 buttons. Kind of like a log report. – Joker Apr 10 '14 at 09:53
  • It depends, you're loading the data via the `SwingWorker`, then you should be able to use the `SwingWorker`'s in built progress functionality to provide feedback to the UI in order to update it. – MadProgrammer Apr 10 '14 at 09:53
  • @MadProgrammer I haven't used swing worker and invoke later. I am thinking of using it so wanted some suggestions. If I intend to use it, I have to change nearly 3000 lines of code to the format. – Joker Apr 10 '14 at 09:56
  • `SwingWorker` generally is easier to use the `invokeLater` - IMHO – MadProgrammer Apr 10 '14 at 10:21
  • @MadProgrammer The main GUI class wasn't framed by me. I framed only few sub classes and connected it with them. Now if I have to change it, I have to get permission and correct the code. It seems like I have to rebuild the code. So what I did is that I created a progress bar class in which progress bar is in Indeterminate mode. Where ever I need I initiated the class and showed and disposed the frame. As a result of this, the glass pane I told about occurs. – Joker Apr 10 '14 at 10:32
  • Have tried just displaying the progress bar frame in isolation to make sure it's working... – MadProgrammer Apr 10 '14 at 10:54
  • @MadProgrammer I actually designed the progress bar as a separate class and then I added it to my app. I am sure it runs. – Joker Apr 10 '14 at 12:51
  • @MadProgrammer So how do I solve that? Make the progress bar a separate thread? – Joker Apr 11 '14 at 05:29
  • 1
    No. The UI must only be interacted with from the context of the EDT. Use the `SwingWorker`, in the `doInBackground` method do your long running operations, if you know how much work you have to do, you can use `setProgress` to trigger a `PropertyChange` event which your progress window can display... – MadProgrammer Apr 11 '14 at 05:33
  • @MadProgrammer I get it now. I invoke UI components using invokeLater,do my Process in background which updates the progress bar. I can use done method to perform operations that I want to do after the completion of my long running process. Thanks for your help. – Joker Apr 12 '14 at 05:28
  • Why not just call `setProgress` and use a `PropertyChangeListener` to update the progress bar? – MadProgrammer Apr 12 '14 at 05:48