How a simple GUI problem can get messy - patterns to the rescue?

Hello everybody!

I'm facing a problem in designing a GUI which appeared quite simple at
first glance but got montrous by the time passing.

The objective is as followes. Suppose having these two different GUI
widgets:

(A) a slider
(B) an edit field

These widges interact, so when the slider position is changed, the
value in the edit field gets modified, too, and vice versa.


Things get complicated due to the fact that the edit value does not
resemble the position of the slider directly or by a fixed proportion.
The slider range can be dynamically set by the user so that it might
represent a scale from 1 to 10, 1 to 100 or even 52 to 387.

The transformation logic "slider <-> edit field" must not be included
in the GUI form itself because this provides the form with to much
intelligence. Instead it shall reside in a seperate object that can
exchange information with the form.

But how do I implement this. Command, Observer, Visitor? What would
you do?

Thanks for reading and kind regards,
Malte

---

The above e-mail address is not valid.
To contact me, please use my real
e-mail address:

malte AT t DASH online DOT de

Just replace the capitalized words with
the corresponding punctuation marks.

>I'd look at "model view controller" also known as MVC.

Being not familiar with SmallTalk and relatively new to patterns I was
totally unaware of the MVC concept. Well, at the risk of getting
struck by lightning instantaneously I even thought that MVC had
something to do with Microsoft Visual C++.

So thank you very much for the information, MVC is exactly what I was
looking for.

Regards,
Malte

---

The above e-mail address is not valid.
To contact me, please use my real
e-mail address:

malte AT t DASH online DOT de

Just replace the capitalized words with
the corresponding punctuation marks.

<brougham5@yahoo.com> wrote in message
news:ms65pv42sm0hoqus0vbk07pgok1klsf046@4ax.com...
> Malte Persike <malte@nospam.com> wrote:
>
> >The transformation logic "slider <-> edit field" must not be included
> >in the GUI form itself because this provides the form with to much
> >intelligence. Instead it shall reside in a seperate object that can
> >exchange information with the form.
> >
> >But how do I implement this. Command, Observer, Visitor? What would
> >you do?
>
> I'd look at "model view controller" also known as MVC.

You might also want to look at a variant called Model-View-Presenter.

"Malte Persike" <malte@nospam.com> wrote in message
news:rsm3pv04emkejdftnfce2r5511fgifk6tt@4ax.com...
> Hello everybody!
>
> I'm facing a problem in designing a GUI which appeared quite simple at
> first glance but got montrous by the time passing.
>


You may find the following article of interest --

http://www.objectmentor.com/resource...eDialogBox.pdf

It is covers creating a GUI application test-first which results in
separating application logic out of the GUI. IOW it illustrates a good
design.

HTH
Shane


--
shanemingins@yahoo.com.clothes

remove clothes before replying

"It is not the strongest of the species that survive, nor the most
intelligent, but the one most responsive to change." --- Charles Darwin

<gmarremoveentette@neo.rrremovetoo.com> wrote:

>You might also want to look at a variant called Model-View-Presenter.


Good advice. I found an informative series of articles on MVP and its
implementation (in Delphi, though) here:

http://www.btinternet.com/~joannac/

Regards,
Malte

---

The above e-mail address is not valid. To
contact me, please use my real e-mail address:

malte AT t DASH online DOT de

Just replace the capitalized words with the
corresponding punctuation marks.