Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #1155 > unrolled thread

GUI structure

Back to article view | Back to comp.lang.java.gui

Contents

  GUI structure "dwj" <dwj@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000
    Re: GUI structure "tar" <tar@THRWHITE.remove-dii-this> - 2011-04-27 15:31 +0000

#1155 — GUI structure

  To: comp.lang.java.gui
My application... I have a series of image processing filters which are
derived from an IFilter base class.  The filters which are applied to
an image are decided by the user (the user uses a tick box to select
them).  These are then stored in a list which are iterated through
when a new image arriveds.

My problem... Each of the image processing filters has its own set of
bespoke attributes (such as threshold) that I want the user to be able
to view and set.  When these are set, I then want them to be updated
in the filter object which the values apply to.  I was thinking of
creating a different form for each filter to set and view the
attributes but I am unsure how I should link the forms to the filter
classes.  An instance of each filter class won't always exist.

Is it as simple as just creating an association between the form and
relevant filter?  This doesn't seem like very good design.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#1158

  To: comp.lang.java.gui
"dwj" <danielwatkinslearn@hotmail.com> writes:

> My problem... Each of the image processing filters has its own set of
> bespoke attributes (such as threshold) that I want the user to be able
> to view and set.  When these are set, I then want them to be updated
> in the filter object which the values apply to.  I was thinking of
> creating a different form for each filter to set and view the
> attributes but I am unsure how I should link the forms to the filter
> classes.  An instance of each filter class won't always exist.

One approach would be to have your filter classes implement a method
that either returns a dialog item to set its options, or else invokes a
dialog and sets its options.

That provides a link between the option form and the class, and doesn't
involve any instance at all.  This will solve the problem for the case
where you want to set an individual filter's options or parameters.

It doesn't solve the case of having a general default set of attributes
available that can be set and persist independent of any particular
filter instance.  That would be a bit more complicated, and would
involve having some data structure that holds the option information.
(Perhaps this data structure could be a dialog object itself?) and the
use of static storage and methods in the filter classes.

-- 
Thomas A. Russ,  USC/Information Sciences Institute

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web