Prev: Free Session Tonight on Example Driven Development w Fit - London
Next: SETP-08 Call for papers
From: naumansulaiman on 22 Oct 2007 12:03
Hi, I am developing an MFC Windows application which consists of a
series
of screens ( dialog boxes). Each screen will have its controls
(buttons etc).
Each button has its own image assigned to it. The app will be able to
run
on any display res type PocketPC or Smartphone high, low res,
portrait,
landscape and square. So already i have the following cases to handle:

1. PPC Portrait low res
2.PPC Portrait high res
2. PPC Landscape low res
3. PPC Landscape high res
4. PPC Square low res

......
same for Smartphone

Windows provides functions to find the orientation and resolution. For
each case
i may be loading a particular image (can't use SVG graphics in
Windows) into
my button controls for any particular screen. Rather than using a big
CASE
statement everywhere iwas wondering if there was any type of pattern
that
could solve this problem.

From: Daniel Pitts on 22 Oct 2007 14:36
On Oct 22, 9:03 am, naumansulai...(a)googlemail.com wrote:
> Hi, I am developing an MFC Windows application which consists of a
> series
> of screens ( dialog boxes). Each screen will have its controls
> (buttons etc).
> Each button has its own image assigned to it. The app will be able to
> run
> on any display res type PocketPC or Smartphone high, low res,
> portrait,
> landscape and square. So already i have the following cases to handle:
>
> 1. PPC Portrait low res
> 2.PPC Portrait high res
> 2. PPC Landscape low res
> 3. PPC Landscape high res
> 4. PPC Square low res
>
> .....
> same for Smartphone
>
> Windows provides functions to find the orientation and resolution. For
> each case
> i may be loading a particular image (can't use SVG graphics in
> Windows) into
> my button controls for any particular screen. Rather than using a big
> CASE
> statement everywhere iwas wondering if there was any type of pattern
> that
> could solve this problem.

I would suggest externalizing the data into a set of files, one for
each "case". Then have your code select which data file to use based
on what the functions return. If you use a good naming convention,
you might be able to do the transform as easily as some simple string
operation or array index lookup. Don't forget to handle the case
where you're code doesn't understand what was given to it.

Hope this helps,
Daniel.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress>

From: H. S. Lahman on 23 Oct 2007 11:46
Responding to Naumansulaiman...

> Hi, I am developing an MFC Windows application which consists of a
> series
> of screens ( dialog boxes). Each screen will have its controls
> (buttons etc).
> Each button has its own image assigned to it. The app will be able to
> run
> on any display res type PocketPC or Smartphone high, low res,
> portrait,
> landscape and square. So already i have the following cases to handle:
>
> 1. PPC Portrait low res
> 2.PPC Portrait high res
> 2. PPC Landscape low res
> 3. PPC Landscape high res
> 4. PPC Square low res
>
> .....
> same for Smartphone
>
> Windows provides functions to find the orientation and resolution. For
> each case
> i may be loading a particular image (can't use SVG graphics in
> Windows) into
> my button controls for any particular screen. Rather than using a big
> CASE
> statement everywhere iwas wondering if there was any type of pattern
> that
> could solve this problem.

I basically agree with Pitts. Shortly after GUIs became available the
world was deluged with window builder applications. That's because the
differences between one dialog and another can be readily expressed in
terms of data values. As you point out, Windows provides API functions
for handling things like aspect ratios and pixel resolution. All you
have to provide is the right data parameters to those functions. So I
think you need something like:

[Dialog]
+ aspect_ratio // PORTRAIT, LANDSCAPE, SQUARE codes
+ resolution // LOW, HIGH codes
+ title
+ message_text
....

When a Dialog is instantiated, you provide the proper values for the
presentation along with the problem-specific information. Then the same
method can extract the values and pass them to the Window Manager. So
there is no need for a switch statement; the differences are all in
object instance attributes that the method extracts for the Dialog
instance in hand.

[Note that the method can also convert from codes like SQUARE and LOW
into whatever the OS Window Manager understands. This allows you to
express the overall UI in problem terms rather than Window Manager terms.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: ManicQin on 24 Oct 2007 04:07

> When a Dialog is instantiated, you provide the proper values for the
> presentation along with the problem-specific information. Then the same
> method can extract the values and pass them to the Window Manager. So
> there is no need for a switch statement; the differences are all in
> object instance attributes that the method extracts for the Dialog
> instance in hand.

But the "proper values for the presentation" are determined by the
platform...
hence you still need a "switch statement" to sort out the values...

did I miss something?

From: H. S. Lahman on 24 Oct 2007 13:25
Responding to ManicQin...

>>When a Dialog is instantiated, you provide the proper values for the
>>presentation along with the problem-specific information. Then the same
>>method can extract the values and pass them to the Window Manager. So
>>there is no need for a switch statement; the differences are all in
>>object instance attributes that the method extracts for the Dialog
>>instance in hand.
>
>
> But the "proper values for the presentation" are determined by the
> platform...
> hence you still need a "switch statement" to sort out the values...

That's why god invented configuration files. B-) One instantiates the
objects based on configuration data for the platform in hand. The
factory objects that do that sort of thing don't need switch statements;
they just plug in values read from the configuration file. (Not quite
true; one will probably need some switch statements to parse the
configuration data.) Once the objects are created, they are the "right"
ones for the platform, so no one needs switch statements to interpret them.

Note that all window builders essentially work in a similar manner. The
entire GUI is defined in data contained in configuration files like
Windows resource files. That allows exactly the same GUI subsystem code
to be reused across multiple applications.

Corollary: the subsystem that encapsulates a particular UI paradigm
should be reusable across applications if the invariants of the UI
paradigm (e.g., Window/Control for a GUI or Page/Section for a browser)
are encoded while detailed differences are relegated to external
configuration data that is application-specific. Among other things,
that allows one to modify the UI without touching the code or even
recompiling.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



 | 
Pages: 1
Prev: Free Session Tonight on Example Driven Development w Fit - London
Next: SETP-08 Call for papers