Hi all,
Do any of you have an efficient way of managing screen attributes when you have so many combinations of them? What is the secret when one screen has different fonts with different sizes and different aspects such as Width+.Width- and some are bold, some are not.
My growing list of attributes in WBCONFIG.SYS is getting longer by the day. And to distinguish between some of them, my attribute names are growing past the length limit and I have to abbreviate the names to the point where I can't remember the distinctions without looking them up.
[ArialSmallestBold]
[ArialSmallerBold]
[ArialSmallBold]
[ArialSmallestNormal]
[ArialMediumItalic]
[LucidaConsoleMediumBold]
[CourierSmallBold]
etc
And then there are the colors to deal with for each of these too. If you are using a non-default font AND it has a non-default color, you have to pre-build those as bracketed attributes too - either in BRCONFIG.SYS or in CONFIG statements in your programs.
I wish you could just concatenate the components on the fly in your input spec -
like [Font][Size][Width][Aspect], etc
all in the same spec - and only have to maintain the basic components in BRCONFIG.SYS. It seems like the possible numbers of combinations are exponential.
Or do most of you avoid "finessing" your screen fonts and only use a few? I may be missing the forest for the trees here.
-- Susan
Managing Screen Attributes
Moderators: Susan Smith, admin, Gabriel
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
I've done quite a bit of work with attributes. If you recall I did a nifty-neat-o on my "Theme Editor" a few years ago at a BRG conference. I defined a Theme as a collection of Attributes. Now I'm adding more properties (like background pic and min. font size).
My advice is to avoid attributes like [Times New Roman] or [Bold] or [Underline] because they're describing *what* the attribute does. And instead use attributes like [Heading] or [Caption] or [Title] or [Footer] or [Button] because those names describe *why* the attribute does and will help you to avoid long term confusion as you grow more flexible down the road.
As a theme is a collection of attributes - The theme is choosen by our user. Each attribute can be modified. The end user can not add nor remove attributes from the theme, only change their properties (width, color, font, etc)
I hope this helps.
-John
My advice is to avoid attributes like [Times New Roman] or [Bold] or [Underline] because they're describing *what* the attribute does. And instead use attributes like [Heading] or [Caption] or [Title] or [Footer] or [Button] because those names describe *why* the attribute does and will help you to avoid long term confusion as you grow more flexible down the road.
As a theme is a collection of attributes - The theme is choosen by our user. Each attribute can be modified. The end user can not add nor remove attributes from the theme, only change their properties (width, color, font, etc)
I hope this helps.
-John
Within BR, using their built in Help.
F1
3. Wbconfig.sys Specifications
1. ATTRIBUTE specification (3.61)
Page Down to the very bottom of the document.
There is a nice "Attribute List".
Attribute Description
[A] active data field (used with INPUT FIELDS ATTR)
[D] data field P - protected/display only field
[S] screen prompts/color
[L] light bar (INPUT SELECT, on-line help screens)
[W] window (general data), on-line help menus
[X] borders for windows (general data)
[E] error field/window color
[F] border for error windows
[G] dialogue window color
[H] dialogue window border
information messages
[M] menu color
[N] menu border color
[T] selection window color
selection window border color
Back in BR 3.5 was originally documented with these codes. I think originally only 1 character was supported.
As long as you are starting fresh, you might want to take that chart, expand the fields to better names, and perhaps add a few.
The point is don't Code to "Artistic Taste", rather code to "Themes or Purposes".
We use about 30 of these categories including strange wones like '[W_WINGDINGS]' and Attributes for the built in help like [HMENU].
As John mentioned, we built a GUI UI that lets you edit/maintain attributes.
Here is a sample set of attributes that one of our customers came out with:
ATTRIBUTE [W_WINGDINGS2] FOREGROUND=#000000 BACKGROUND=#ECE9D8
WINGDINGS 2:MEDIUM:LIGHT
ATTRIBUTE [UNDERLINE] FOREGROUND=#FFFFFF BACKGROUND=#8EA9A9
UNDER
ATTRIBUTE [T_WINGDINGS2] FOREGROUND=#000000 BACKGROUND=#FFFFFF
WINGDINGS 2:MAX:WIDTH:LIGHT
ATTRIBUTE [TOOLBAR] FOREGROUND=#000000 BACKGROUND=#AACCFF
VERDANA:MAX:WIDTH-
ATTRIBUTE [TABS] FOREGROUND=#000000 BACKGROUND=#66B4B4
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [INACTIVE] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:MAX:WIDTH-
ATTRIBUTE [FIXED] FOREGROUND=#000000 BACKGROUND=#FFFFFF
SYSTEMPC:MAX:WIDTH+
ATTRIBUTE [DISABLED] FOREGROUND=#000000 BACKGROUND=#BBE4F3
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [CONSOLE] FOREGROUND=#316AC5 BACKGROUND=#FFFFFF
SYSTEMPC
ATTRIBUTE [BUTTON_CUI] FOREGROUND=#FFFFFF BACKGROUND=#6E8989
VERDANA:MEDIUM:WIDTH:BOLD
ATTRIBUTE [BUTTON] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:SMALL:WIDTH+:LIGHT
ATTRIBUTE [HMENU] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
ATTRIBUTE [HLIGHTBAR] FOREGROUND=#FFFFFF BACKGROUND=#316AC5
ATTRIBUTE [HTEXT] FOREGROUND=#983535 BACKGROUND=#ECE9D8
ATTRIBUTE [HPROMPT] FOREGROUND=#FFFF00 BACKGROUND=#405353
ATTRIBUTE FOREGROUND=#FFFFFF BACKGROUND=#6E8989
VERDANA:MEDIUM:WIDTH:BOLD
ATTRIBUTE FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX
ATTRIBUTE [T] FOREGROUND=#000000 BACKGROUND=#FFFFFF
TAHOMA:MAX:WIDTH:LIGHT
ATTRIBUTE [N] FOREGROUND=#FFFFFF BACKGROUND=#6E8989
TAHOMA:MAX:WIDTH+:SLANT:BOLD
ATTRIBUTE [M] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
ARIAL:MEDIUM:WIDTH:LIGHT
ATTRIBUTE [F] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:SMALL:NOWIDTH:ITAL
ATTRIBUTE [E] FOREGROUND=#FFFFFF BACKGROUND=#8E8B8B
ARIAL:MEDIUM:NOWIDTH:ITAL
ATTRIBUTE [X] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX
ATTRIBUTE [W] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:MEDIUM:LIGHT
ATTRIBUTE [L] FOREGROUND=#FFFFFF BACKGROUND=#316AC5
VERDANA:MAX:WIDTH:BOLD
ATTRIBUTE [S] FOREGROUND=#983535 BACKGROUND=#ECE9D8
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [P] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX:WIDTH-
ATTRIBUTE [D] FOREGROUND=#000000 BACKGROUND=#FFFFFF
VERDANA:MAX:WIDTH-
ATTRIBUTE [A] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
VERDANA:MAX:WIDTH-:LIGHT
F1
3. Wbconfig.sys Specifications
1. ATTRIBUTE specification (3.61)
Page Down to the very bottom of the document.
There is a nice "Attribute List".
Attribute Description
[A] active data field (used with INPUT FIELDS ATTR)
[D] data field P - protected/display only field
[S] screen prompts/color
[L] light bar (INPUT SELECT, on-line help screens)
[W] window (general data), on-line help menus
[X] borders for windows (general data)
[E] error field/window color
[F] border for error windows
[G] dialogue window color
[H] dialogue window border
information messages
[M] menu color
[N] menu border color
[T] selection window color
selection window border color
Back in BR 3.5 was originally documented with these codes. I think originally only 1 character was supported.
As long as you are starting fresh, you might want to take that chart, expand the fields to better names, and perhaps add a few.
The point is don't Code to "Artistic Taste", rather code to "Themes or Purposes".
We use about 30 of these categories including strange wones like '[W_WINGDINGS]' and Attributes for the built in help like [HMENU].
As John mentioned, we built a GUI UI that lets you edit/maintain attributes.
Here is a sample set of attributes that one of our customers came out with:
ATTRIBUTE [W_WINGDINGS2] FOREGROUND=#000000 BACKGROUND=#ECE9D8
WINGDINGS 2:MEDIUM:LIGHT
ATTRIBUTE [UNDERLINE] FOREGROUND=#FFFFFF BACKGROUND=#8EA9A9
UNDER
ATTRIBUTE [T_WINGDINGS2] FOREGROUND=#000000 BACKGROUND=#FFFFFF
WINGDINGS 2:MAX:WIDTH:LIGHT
ATTRIBUTE [TOOLBAR] FOREGROUND=#000000 BACKGROUND=#AACCFF
VERDANA:MAX:WIDTH-
ATTRIBUTE [TABS] FOREGROUND=#000000 BACKGROUND=#66B4B4
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [INACTIVE] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:MAX:WIDTH-
ATTRIBUTE [FIXED] FOREGROUND=#000000 BACKGROUND=#FFFFFF
SYSTEMPC:MAX:WIDTH+
ATTRIBUTE [DISABLED] FOREGROUND=#000000 BACKGROUND=#BBE4F3
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [CONSOLE] FOREGROUND=#316AC5 BACKGROUND=#FFFFFF
SYSTEMPC
ATTRIBUTE [BUTTON_CUI] FOREGROUND=#FFFFFF BACKGROUND=#6E8989
VERDANA:MEDIUM:WIDTH:BOLD
ATTRIBUTE [BUTTON] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:SMALL:WIDTH+:LIGHT
ATTRIBUTE [HMENU] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
ATTRIBUTE [HLIGHTBAR] FOREGROUND=#FFFFFF BACKGROUND=#316AC5
ATTRIBUTE [HTEXT] FOREGROUND=#983535 BACKGROUND=#ECE9D8
ATTRIBUTE [HPROMPT] FOREGROUND=#FFFF00 BACKGROUND=#405353
ATTRIBUTE FOREGROUND=#FFFFFF BACKGROUND=#6E8989
VERDANA:MEDIUM:WIDTH:BOLD
ATTRIBUTE FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX
ATTRIBUTE [T] FOREGROUND=#000000 BACKGROUND=#FFFFFF
TAHOMA:MAX:WIDTH:LIGHT
ATTRIBUTE [N] FOREGROUND=#FFFFFF BACKGROUND=#6E8989
TAHOMA:MAX:WIDTH+:SLANT:BOLD
ATTRIBUTE [M] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
ARIAL:MEDIUM:WIDTH:LIGHT
ATTRIBUTE [F] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:SMALL:NOWIDTH:ITAL
ATTRIBUTE [E] FOREGROUND=#FFFFFF BACKGROUND=#8E8B8B
ARIAL:MEDIUM:NOWIDTH:ITAL
ATTRIBUTE [X] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX
ATTRIBUTE [W] FOREGROUND=#000000 BACKGROUND=#ECE9D8
TAHOMA:MEDIUM:LIGHT
ATTRIBUTE [L] FOREGROUND=#FFFFFF BACKGROUND=#316AC5
VERDANA:MAX:WIDTH:BOLD
ATTRIBUTE [S] FOREGROUND=#983535 BACKGROUND=#ECE9D8
ARIAL:MAX:WIDTH+:BOLD
ATTRIBUTE [P] FOREGROUND=#000000 BACKGROUND=#ECE9D8
VERDANA:MAX:WIDTH-
ATTRIBUTE [D] FOREGROUND=#000000 BACKGROUND=#FFFFFF
VERDANA:MAX:WIDTH-
ATTRIBUTE [A] FOREGROUND=#316AC5 BACKGROUND=#BFD2D2
VERDANA:MAX:WIDTH-:LIGHT
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
John, I DO understand about using the FUNCTION of the attributes as the name. But what if you want distinctions between fields (more than caption, input, header, etc)?
I should mention that mine users will NEVER customize any of it. They just won't. Perhaps they will choose their Windows theme, desktop and screensaver, but that's as far as they will go. They are just barely beyond computer illiterate (well, 2/3 of them anyway). Secondly, in your application, how do you guarantee that your user won't chose something that doesn't work? (fonts too large to see the data, for example, or just plain stupid looking attributes that make your application look cheesy and amateurish?)
I don't worry so much about listviews and such, but I want my input screens to look nice and professional and well-balanced. If the user can choose something that will result in data not being visible (either too large to fit the input field, or foreground=background, etc) - how do you protect against that?
This all started (for me) because I have a check-writing screen where the user inputs the data onto a colored background that looks like a check (and the color of the check matches their paper checks for the company they are presently working with). So if I allowed them to use background attributes (besides transparent), then it would destroy the look of that background. Likewise, I want particular data to stand out for various reasons, so I wanted that font larger, in a different color, Bold (or all of these). That's where I got started on this journey.
You and I have a different target audience. I understand what you are doing with your users (you have thousands of people using your application - I have 12 - most of whom are over 60 with eye sight issues). Are you saying that you really use ONE caption and ONE heading and ONE input field spec for all of your system?
-- Susan
I should mention that mine users will NEVER customize any of it. They just won't. Perhaps they will choose their Windows theme, desktop and screensaver, but that's as far as they will go. They are just barely beyond computer illiterate (well, 2/3 of them anyway). Secondly, in your application, how do you guarantee that your user won't chose something that doesn't work? (fonts too large to see the data, for example, or just plain stupid looking attributes that make your application look cheesy and amateurish?)
I don't worry so much about listviews and such, but I want my input screens to look nice and professional and well-balanced. If the user can choose something that will result in data not being visible (either too large to fit the input field, or foreground=background, etc) - how do you protect against that?
This all started (for me) because I have a check-writing screen where the user inputs the data onto a colored background that looks like a check (and the color of the check matches their paper checks for the company they are presently working with). So if I allowed them to use background attributes (besides transparent), then it would destroy the look of that background. Likewise, I want particular data to stand out for various reasons, so I wanted that font larger, in a different color, Bold (or all of these). That's where I got started on this journey.
You and I have a different target audience. I understand what you are doing with your users (you have thousands of people using your application - I have 12 - most of whom are over 60 with eye sight issues). Are you saying that you really use ONE caption and ONE heading and ONE input field spec for all of your system?
-- Susan
"what if you want distinctions between fields (more than caption, input, header, etc)? "
make more attributes like caption_primary and caption_secondary or header_1 and header_2 and header_3 for various levels of headers. html does this and then you can use CSS to change what those headers look like, however header_1 is almost always the top level.
In my application I do NOT force users not to pick black on black. Or small enough fonts. I let them pick the settings they want - the settings they think look good. I provide them with several themes that work great. If they turn the font size up and have to resize their screen to see all of whatever than they know that they changed that setting and why it is that way. Windows likewise does not disallow black on black or other dorky looking theme options. You put it to what you want and it stays that way until you change it. You can always go back to the default.
I'd say that your check screen should probably have an image of a check in the background or even a [Check_Base] attribute that is set to the color of the check.
It' is sometimes difficult to balance users that want every field to look different and also maintain consistency accross your software and consistency with other windows apps.
We do have different audiences. I really use one caption, one footer, one grid_active, one grid_inactive, one textbox_enabled, one textbox_disabled, etc across my whole system. The names are not ideal.... for example a disable text box is [P]. It's not easy to recognize what it means (actually stands for protected) but it does let me change all of my disabled fields at the same time and maintain a consistent look and feel across our entire suite of software.
You'll not want to abandon your old attributes, but embrace them instead. You might want to refactor them, but who cares? The important part is that you make yourself a chart of every attribute you've ever used and document on that chart what the purpose of the attribute is. This should help you with new coding a great deal... my chart helps me!!!
-john
make more attributes like caption_primary and caption_secondary or header_1 and header_2 and header_3 for various levels of headers. html does this and then you can use CSS to change what those headers look like, however header_1 is almost always the top level.
In my application I do NOT force users not to pick black on black. Or small enough fonts. I let them pick the settings they want - the settings they think look good. I provide them with several themes that work great. If they turn the font size up and have to resize their screen to see all of whatever than they know that they changed that setting and why it is that way. Windows likewise does not disallow black on black or other dorky looking theme options. You put it to what you want and it stays that way until you change it. You can always go back to the default.
I'd say that your check screen should probably have an image of a check in the background or even a [Check_Base] attribute that is set to the color of the check.
It' is sometimes difficult to balance users that want every field to look different and also maintain consistency accross your software and consistency with other windows apps.
We do have different audiences. I really use one caption, one footer, one grid_active, one grid_inactive, one textbox_enabled, one textbox_disabled, etc across my whole system. The names are not ideal.... for example a disable text box is [P]. It's not easy to recognize what it means (actually stands for protected) but it does let me change all of my disabled fields at the same time and maintain a consistent look and feel across our entire suite of software.
You'll not want to abandon your old attributes, but embrace them instead. You might want to refactor them, but who cares? The important part is that you make yourself a chart of every attribute you've ever used and document on that chart what the purpose of the attribute is. This should help you with new coding a great deal... my chart helps me!!!
-john
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
This is very good advice. I will start a chart today and I'll include which attributes are used on which screen. An additional benefit that I can see right away is that IF I wanted to restructure my attribute names down the line, I can readily see where (or IF) an attribute is used. Great idea. Thanks.
-- Susan
-- Susan
The important part is that you make yourself a chart of every attribute you've ever used and document on that chart what the purpose of the attribute is. This should help you with new coding a great deal... my chart helps me!!!
I do it like this: I have a few different theme.sys files that describe different color themes. Here is an example file, called ThmeBlue.sys, describing a blue theme. It includes color.sys which provides the basic color definitions (this helps me keep things readable) and then it provides a definition for how each of my field elements is supposed to look with the Blue theme. Finally, it has a Screen statement that sets the background of the screen to blue:
Then I have a color.sys file. This defines the colors in english readable words. Mine looks like this:
However you would probably add some additional values here such as [UNDERLINE] and [Different Fonts].
The secret is the theme files. The color file simply maps each possible attribute to a human readable word to help keep the theme files readable. The theme file assigns a color to each element used in my programs.
This allows me to put together three or four different theme files, for example a ThemeBlue.sys, a ThemeGreen.Sys, a ThemeModern.sys, a ThemeBlindPeople.sys, and I allow the user to select one of these theme files.
They don't choose how each element of the screen looks, but they're able to select from different looks that I have already created, and that I know look good together..
But the most important thing is, breaking it up this way allows me to quickly change the look and feel of their entire application, any time I think something needs to look better.
My clients software was originally the old 16 color dark blue that many older programs used. I was able to change this color to a much lighter looking more modern color by updating his Screen statement in the themeblue.sys file. When I discovered that the old Active Input color clashed with the new lighter blue, I was able to change it in themeblue.sys and it instantly fixed the problem everywhere.
For programs that require a specific look or feel, like your check program, I simply don't use the themes for those places in my software. If the background color for the check comes from the clients data file, then let it. If you need to find a foreground color that looks good on all of them, specify it the old way.
But by having two layers of attributes files, (a color.sys file giving me human readability and one or more theme files giving me changeability and maintainability), I'm able to quickly adjust the look and feel of my programs at any time without any of the headaches.
For my biggest client, I was able to spend a few minutes changing their theme file, and make it look like they had an entirely new software suite, a jump from the 80s to the 2000s. My boss for that company, the programmer who writes the checks wasn't that impressed. But the end users, the secretaries who use the programs on a day to day basis, got to feel like they were getting something entirely new to play with when in reality it took me less then 10 minutes to implement.
Gabriel
Code: Select all
include color.sys
ATTRIBUTE [BUTTONS] /[BLACK]:[LTGREY]
ATTRIBUTE [LVHEADERS] /[BLACK]:[LTGREY]
ATTRIBUTE [HILITE] /[DKYELLOW]:[BLUE]
ATTRIBUTE [BOLD] /[DKYELLOW]:[BLUE]
ATTRIBUTE [INPUT] S/[BLACK]:[LTBLUE]
ATTRIBUTE [ACTIVEINPUT] /[BLACK]:[LTYELLOW] ! Active Input for multi input screens
ATTRIBUTE [BACKGROUND] /[BLACK]:[BLUE]
ATTRIBUTE [BACKGROUND2] /[WHITE]:[BABYBLUE]
ATTRIBUTE [ERROR] /[DKRED]:[LTBLUE]
ATTRIBUTE [INVISIBLE] /[BLUE]:[BLUE]
ATTRIBUTE [PROTECTED] /[BLACK]:[LTGREY]
ATTRIBUTE [DATEWINDOW] /[WHITE]:[ANOTBLUE]
ATTRIBUTE [CONTCUR] /[BLACK]:[LTGREEN]
ATTRIBUTE [FCONTCUR] /[BLACK]:[BLUEGREEN]
ATTRIBUTE [CONTSENT] /[BLACK]:[MYELLOW]
ATTRIBUTE [FCONTSENT] /[BLACK]:[SYELLOW]
ATTRIBUTE [CONTNOTSENT] /[BLACK]:[ORANGE]
ATTRIBUTE [NOCONTRACT] /[BLACK]:[LTRED]
SCREEN U [INPUT], N [BACKGROUND],S [BACKGROUND],H [HILITE], B [HILITE], R [ACTIVEINPUT]Code: Select all
COLOR [LTGREY] #CCCCCC
COLOR [LTBLUE] #AFCFFF
COLOR [LTYELLOW] #FFFF77
COLOR [LTRED] #FF5050
COLOR [PURPLE] #FF77FF
COLOR [GREEN] #00FF00
COLOR [LTGREEN] #50FF50
COLOR [RED] #FF0000
COLOR [BLUE] #83AEF7
COLOR [YELLOW] #FFFF00
COLOR [SYELLOW] #FFFFAF
COLOR [MYELLOW] #FFFF50
COLOR [MAGENTA] #FF00FF
COLOR [CYAN] #00FFFF
COLOR [BLACK] #000000
COLOR [WHITE] #FFFFFF
COLOR [BABYBLUE] #0066FF
COLOR [DKRED] #A00000
COLOR [DKYELLOW] #0F0F00
COLOR [DKGREEN] #007700
COLOR [BLUEGREEN] #00FFAF
COLOR [ANOTBLUE] #3333FF
COLOR [ORANGE] #FF8000The secret is the theme files. The color file simply maps each possible attribute to a human readable word to help keep the theme files readable. The theme file assigns a color to each element used in my programs.
This allows me to put together three or four different theme files, for example a ThemeBlue.sys, a ThemeGreen.Sys, a ThemeModern.sys, a ThemeBlindPeople.sys, and I allow the user to select one of these theme files.
They don't choose how each element of the screen looks, but they're able to select from different looks that I have already created, and that I know look good together..
But the most important thing is, breaking it up this way allows me to quickly change the look and feel of their entire application, any time I think something needs to look better.
My clients software was originally the old 16 color dark blue that many older programs used. I was able to change this color to a much lighter looking more modern color by updating his Screen statement in the themeblue.sys file. When I discovered that the old Active Input color clashed with the new lighter blue, I was able to change it in themeblue.sys and it instantly fixed the problem everywhere.
For programs that require a specific look or feel, like your check program, I simply don't use the themes for those places in my software. If the background color for the check comes from the clients data file, then let it. If you need to find a foreground color that looks good on all of them, specify it the old way.
But by having two layers of attributes files, (a color.sys file giving me human readability and one or more theme files giving me changeability and maintainability), I'm able to quickly adjust the look and feel of my programs at any time without any of the headaches.
For my biggest client, I was able to spend a few minutes changing their theme file, and make it look like they had an entirely new software suite, a jump from the 80s to the 2000s. My boss for that company, the programmer who writes the checks wasn't that impressed. But the end users, the secretaries who use the programs on a day to day basis, got to feel like they were getting something entirely new to play with when in reality it took me less then 10 minutes to implement.
Gabriel
-
Susan Smith
- Posts: 717
- Joined: Sun Aug 10, 2008 4:24 am
- Location: Southern California
Hi Gabriel,
I remember your presentation on color themes in 2008 at one of the conferences. Thanks for the reminder. In my case, I'm referring more to fonts than colors (although colors of fonts may come into play as well).
Can you use themes for attributes other than colors? This would be cool, but I don't see a way.
I may use color themes in the future as I can see that it adds some very helpful centralization. The combinations of font attributes is still pretty messy ;(
-- Susan
I remember your presentation on color themes in 2008 at one of the conferences. Thanks for the reminder. In my case, I'm referring more to fonts than colors (although colors of fonts may come into play as well).
Can you use themes for attributes other than colors? This would be cool, but I don't see a way.
I may use color themes in the future as I can see that it adds some very helpful centralization. The combinations of font attributes is still pretty messy ;(
-- Susan
Yes, You can. Thats what I'm trying to say.Can you use themes for attributes other than colors? This would be cool, but I don't see a way.
My example is limited to color because at that client they use the default font, so my example is limited. But the concept should apply to ANY attribute statement.
Gabriel[/quote]
Another way to use COLOR is to orient the color name to intensity and then make up your themes of primary and secondary colors with various intensities. You can come up lots of different themes consisting of contrasted colors of varying intensity.
For example:
COLOR [pri-1] #111111 ! light
COLOR [pri-2] #222222
COLOR [pri-3] #333333
COLOR [pri-4] #444444 !dark
COLOR [sec-1] #aaaaaa
COLOR [sec-2] #bbbbbb
COLOR [sec-3] #cccccc
COLOR [sec-4] #dddddd
ATTRIBUTE [background] /[pri-1]:[pri-1]
ATTRIBUTE [captions] /[sec-3]:[pri-1]
ATTRIBUTE [casual] /[pri-4]:[pri-1]
ATTRIBUTE [strong] /[sec-4]:[pri-2]
ATTRIBUTE [current] /[pri-3]:[sec-1]
ATTRIBUTE [hilite] /[pri-4]:[sec-2]
and so on...
Then the only thing that needs to change from one theme to the next are the eight color definitions. And there are tools for coming up with the spread of shades given a bse color. All a person would need to do is to choose two base colors and the computer could do the rest.
For example:
COLOR [pri-1] #111111 ! light
COLOR [pri-2] #222222
COLOR [pri-3] #333333
COLOR [pri-4] #444444 !dark
COLOR [sec-1] #aaaaaa
COLOR [sec-2] #bbbbbb
COLOR [sec-3] #cccccc
COLOR [sec-4] #dddddd
ATTRIBUTE [background] /[pri-1]:[pri-1]
ATTRIBUTE [captions] /[sec-3]:[pri-1]
ATTRIBUTE [casual] /[pri-4]:[pri-1]
ATTRIBUTE [strong] /[sec-4]:[pri-2]
ATTRIBUTE [current] /[pri-3]:[sec-1]
ATTRIBUTE [hilite] /[pri-4]:[sec-2]
and so on...
Then the only thing that needs to change from one theme to the next are the eight color definitions. And there are tools for coming up with the spread of shades given a bse color. All a person would need to do is to choose two base colors and the computer could do the rest.