• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JDialog child of JDialog

 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a JFrame which has a JDialog which starts a Thread to do a bunch of work. Somtimes the thread has to ask for guidance from the user. I've created another JDialog for this but what do I pass in as the parent owner? ie my super call is :

super(f, "Import Foreign Data", true);

where f is the parent. In my first level dialog I just use the owning frame. In this one I tried to use the owning dialog but it complains it has to be a JFrame. If I just substitute the JFrame, then I lose my handle to do progress updates. Do I really have to pass in both the owning JDialog and the owning JFrame?

What are the best practices for this?

thanks

ms
 
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i'll take a crack at it since no one has responded yet ...


(1) You can cast your parent JDialog as (Dialog)

This will work to get rid of the error about the JFrame...



(2) best practices

i'm no authority, but i've had probs similar to the one you describe, and
i found that i now try to avoid dialog-on-dialog display when i can. it often means extra coding, but it contributes to maintainability and 'usability' in the end.

for example, when background issues occur during a long-running task, i use a clickable, color-coded status indicator (w beep) to warn of problems. the problems may or may not be related to the long-running task. this allows me to design error/exception handling the same way across all tasks, and just use a single error component for the GUI.

in your case, you need user input, so you don't really have a choice about how to handle it. in this case, one option is to add the input components to a morph'ed progress dialog (i.e. prompt for input in the same dlg)... the obvious challenge is to give a clear visual cue, so the user knows that s/he has to do something...


maybe i'm just lazy, but i prefer to deal with as few popup dlgs as possible when i'm trying to do pc work ... so i'm biased

hth
[ August 18, 2004: Message edited by: clio katz ]
 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks
 
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chuck the super()
Instead use setTitle("Your title");

Now, as ur using NO super, u wont have any problem
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic