Bad StatusLine defaults colors when color is changed

[GoogleCodeExporter]

When you change the color of the StatusLine and then sets the "default
color", this is not set correctly.

What steps will reproduce the problem?
1. Run the "color_test.z5" gamefile.
2. Press any key to set new colors.
3. Press any key to restore "default colors"

What is the expected output? What do you see instead?
If StatusLine's colors is different to initial color (in step 1), it is a
Bug! (check the correct behavior: see the image "color_test.jpg". Warning:
in Windows Frotz the default colors are BG: dark blue, FG: white; in
Gargoyle the defults colors are BG: white, FG: black, and StatusLine
Special BG: Grey).

---------------------------------

Another test:
1. Run "dalubi_v2_demo.z5".
2. Press any key.
3. Remember the colors of StatusLine.
4. In main game, type COLOR. The colors are changed.
5. Now type COLOR DEFECTO. The default colors is restored.

What is the expected output? What do you see instead?
If StatusLine's colors is different to initial color (in step 3), it is a Bug!

Original issue reported on code.google.com by eliukb...@gmail.com on 18 Feb 2009 at 9:48

Attachments:

• color_test.z5
• color_test.jpg
• dalubi_v2_demo.z5

[GoogleCodeExporter]

Thanks Eliuk, I'll take a look.

Original comment by bcressey@gmail.com on 6 Mar 2009 at 6:47

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by bcressey@gmail.com on 6 Mar 2009 at 6:51

• Added labels: Component-Logic, Milestone-20090325, OpSys-All, Priority-High, Usability
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by bcressey@gmail.com on 6 Mar 2009 at 6:51

[GoogleCodeExporter]

Original comment by bcressey@gmail.com on 7 Apr 2009 at 9:27

• Added labels: Milestone-20090625
• Removed labels: Milestone-20090325

[GoogleCodeExporter]

Fixed in r185.

The dalubi demo appears to work fine now.

The color_test.z5 still doesn't look quite right, but it appears to be a bug in 
the
supplied test file.  The upper window is collapsed to zero during the erase, 
and is
not resized to 3 subsequently, as it was at the start.

Original comment by bcressey@gmail.com on 3 Jun 2009 at 7:32

• Changed state: Fixed