You want to give your users perfect control over a real-time process? Then you need a toolkit to build a user interface appropriate to human needs. A combination of status bars is such a tool, as you will read in this article (and get its look-and-feel in a demo).

Imagine you have a real-time process involving a great number of parameters. You want to build an application with a user interface giving the users full insight into all its parameters and their interplay. Plus diverse input elements for effective controlling.

How would you present this user interface on screen? - Obviously, it should be a trade-off between:

• user friendliness: upon a glance, users should be able to get a good idea of the current situation (and, if needed, to give their inputs - some parameters will change, requiring new user inputs, …)
• programmer friendliness: it should be easy to combine such a user interface from a small number of components, or to modify it when requirements are changing

In this article the tool  Statusbar()  and some auxiliary components will be introduced. By calling it with various  keyword parameters  (details: Appendix 1: Keyword Params) and  indirect coding  (details: see Appendix 2: Indirect Coding) the most amazing effects can be implemented, just by a few lines of code.

Application

To build a user interface for handling a real-time process, you should patch up your screen with one or any number of status bars, from the bottom up to the top. If there is screen space left between the last status bar and the top screen edge, it can be used for any text or as a work space.

By default, a status bar is a uniform 1-line space that can be filled up by any text you think relevant to the process. This, however, will be useful only in simple cases, involving just a few parameters. For a rather complex process, you will want to:

• Combine a number of status bars (preferably, giving each one a different style). It will make sense to have each status bar reflect a different aspect of the process. After all, the users should be able to comprehend the current situation at one glance!
• Structure each status bar from the uniform 1-line space up to a 1-row table with headers to each field. Normally each table field will be empty at first, to be filled up by the text sent from monitoring the process. As well, however, a field can comprise any standard or custom input - see my article  Custom Inputs for Tailoring the User Interface  (IE version   non-IE version).

Coding

Coding - Style

By default, a  Statusbar  is presented similar to the browser's status bar (grey background, ridge border). If you want to have a more sophisticated layout, you can achieve that in two ways:

1. Semi-permanent Style Change: For your  corporate identity  you might want to have a uniform default layout, every time a  Statusbar()  is launched in an application. Then you should change the Semi-permanent Style Sheet (look into this footnote).
2. Temporary Style Change: If you feel, a  SubDlg  should give a different impression, then you should use the option  style=  to have a different layout for this launch only. (For details look into this footnote.)

If you have several status bars combined on screen, it will be user-friendly to have them in different colors, different font sizes, etc.

By the following button you can get a demo with two  Statusbar , each with different  styles. In it, you might be interested to spy on the source code:

• With the cursor anywhere in the client area of the screen, click the right mouse key. Your browser's context menu will pop up.
• Within the context menu, click the item  View Source Code . Your system's default editor will pop up with the HTML code making up this page.

Coding - Height

By the following button you can get a demo with two  Statusbar , each with different  height . In it, you might be interested to spy on the source code:

• With the cursor anywhere in the client area of the screen, click the right mouse key. Your browser's context menu will pop up.
• Within the context menu, click the item  View Source Code . Your system's default editor will pop up with the HTML code making up this page.

Coding - Table

By default, a  Statusbar  is one empty line with a ridge border. Usually, however, you will want to have a tabular status bar. That's a 1-row table with any number of headers. You can define it by this option:

For the exact formalism see this footnote.

By the following button you can get a demo with two  Statusbar , one of them defined with a  table . In it, the last field is defined by HTML code ( <...> ). The field before the last one is defined by Indirect Coding (the identifier is preceded by  @ ). You might be interested to spy on the source code:

• With the cursor anywhere in the client area of the screen, click the right mouse key. Your browser's context menu will pop up.
• Within the context menu, click the item  View Source Code . Your system's default editor will pop up with the HTML code making up this page.

Coding - Contents

In most cases, you will define a status bar by option  table= , yielding a 1-row table. Only in extreme cases you will want to have a more complex table. Then you will need this option (probably along with Indirect Coding).

Remember, however, the first point in this footnote: If you have to display more variables than can be accommodated in a 1-row table, you should take this as an indication to split them up into several status bars!

This option was provided for extreme cases only. So it was not used in the demo.

Coding - MonitorObj

In the demo there is also an auxiliary tool  MonitorObj  used. Its function is to write a sequence of variables to a status bar. It can be used in two ways:

1. MonitorObj(objMon,objDest,"header=variable ... "[,label])
2. MonitorObj(objMon,objDest,"..."[,label])

Depending on the nature of your real-time process, you might need a different tool for writing variables.

Requirements

• Hardware
• Browser
• include
• call

Click the item you want to know more about!

Requirements - Hardware

• Keyboard:
  Most of the Custom Inputs require keyboard typing.
  Will all your users have a keyboard?
• Mouse:
  All of the Custom Inputs are designed for mouse input.
  Will all your users have a mouse?
• Monitor - Colors, Screen Resolution:
  Some of the Custom Inputs assume multi-chrome monitors.
  Will all your users have a multi-chrome monitor?
  In general, you should be aware of the monitors' size and screen resolution. What will they be at your users'?

Requirements - Browser

Requirements - include

Of course, you should make sure that the JavaScript-File  Input.js  really is in the current working directory on your server. If not, you might have to alter the path, e.g. <SCRIPT SRC="../JS/Input.js"></SCRIPT>

If you want to combine Statusbar()  with any of the other software components described in the other articles of these archives, you should declare them one after the other. E.g.:

Requirements - call

<SCRIPT>Statusbar( … );
    :
Statusbar( … );
    :
Statusbar( … )</SCRIPT>

Appendix 1: Keyword Params

Statusbar()  is based on a software technology that is different to standard programming languages (such as  JavaScript ).

In standard programming languages you can control a function only by  positional parameters . That is, the significance of a parameter is given by its position in the parameter list: the first parameter, the second parameter, etc.

To the human programmer, that's fine as long as there are not more than some 6-10 parameters. Beyond that, it's but too easy to overlook a parameter. Consequently, all the following parameters would be interpreted incorrectly.

That's going to be a problem especially when you have a significant parameter at, say, position 29 - whereas the parameters of position 21 to 28 are not significant. So, to the human mind the most obvious thing would be to leave them out. Alas, then your significant parameter of position 29 would be interpreted as if it were at position 21. Not exactly what you want!

Therefore, the options of  Statusbar()  (and all the other software components presented in these archives) use a software technology called  keyword parameters  (Exact formalism: see this footnote.)

Appendix 2: Indirect Coding

Statusbar()  is very powerful. For title, contents and buttons it can display anything from plain text up to the most complicated HTML constructions. This is more, in fact, than what can be coded simply as a linear string (holding the HTML code of the construction).

Therefore the concept of  Indirect Coding  was introduced:

• Within brackets  <DIV id=…> … </DIV> , the desired HTML construction is coded - as simple as in a normal HTML document.
• Prefixed by  @ , the identifier  …  declared in  id=…  of the opening  DIV-tag is used for the parameter in case, e.g.:
  <DIV id=title> … </DIV>
  <DIV id=contents> … </DIV>
  <DIV id=buttons> … </DIV>
  SubDlg(@contents,"title=@title buttons=@buttons")
• You will not want your page to be defaced by these DIVs. So you should hide them:
  <DIV id=… STYLE="display:none">
      :
  </DIV>
    :   indicates the HTML code of your construction.

• Click the bottom item in the SectionMenu (top-right corner of the screen), named "Semi-permanent Style Sheet".
  If the file type  CSS  is defined in your system, the file  OnlineComm.css  will be opened in your system's default editor right away. If not, you will be prompted first:  Open, or save to disk?  Now you should select  Open . (Have no sorrow - it's your own system's default editor what it will be opened in!)
• Search for the line introduced by  .statusbar 
• In this line, within the brackets  { } , modify the default style as you want. Code it in the usual CSS-notation.
• Finally, don't forget to save the modified file.
• Next time a default  Statusbar()  is launched, it will be in the new layout.

1. Keyword parameters may be coded in any order.
2. The significance of a parameter is given by its prefix (the "keyword").
3. Insignificant parameters can simply be left out.
4. Keywords are case-sensitive. They must be coded exactly as given in the documentation.
5. Keyword parameters ("options") can be simple  keyword  or pairs of  keyword  and  value , separated by  = .
6. Individual keyword parameters must be separated by at least one blank space, if the preceding  value  is not bracketed.
7. In some cases, a keyword parameter might have a few positional parameters. (Their order is significant!)
8. A parameter value may be coded with or without brackets. If it comprises a blank space, however, it must be bracketed in  '' ,  ""  or  «» .
9. The outermost brackets of an option string must be those standard to JavaScript ( ''  or  "" ).
10. If the symbols  «  and  »  are not on your keyboard, you can enter them by:
    • Press the  ALT -key, and
    • on the numeric keypad type "174" (for  « ) or "175" (for  » ).

    E	Deciding on how to nest  "" ,  ''  and  «»  brackets, to code a single apostrophe, or to factor out an expression, can be quite a hairy matter sometimes.

11. The closing apostrophe of the last keyword parameter (be it  ' ,  "  or  » ) may be omitted.
    (Not recommended, however: If the option string is expanded some time later, it is too easy to overlook that!)

In some applications you will want to display some contents, but make sure that the users cannot copy them to clipboard. Thus protecting them from being further processed.

You can do that simply by Indirect Coding of a nested <DIV> which is disabled for selection:

<DIV ID="noselect" STYLE="display:none">
<DIV onselectstart="return false"> … (contents to protect) … </DIV>
</DIV>

	:

SubDlg('@noselect');

• Any number of headers can be defined, simply in one option  table= .
  If you have too many headers, however (= too many columns in your table), the fields will be too narrow to accommodate the text. Then you could consider to use a more complex table (defined by Indirect Coding and option  contents= ).
  Or, this might be the point to introduce new status bars for displaying that mass of information. (Could be more user-friendly!)
• The headers are separated by a semicolon ( ; ).
• The sequence is beginning with  header1 . The very first table field has no header - it will be written later with an indication what this status bar (= all the following fields) is about.
• If a header is beginning with  < , it is taken to be the HTML code of an input. (In the following demo, the button  back  - to get back to the main window - is defined in this way.)
• If a header is preceded by  @ , it is taken to be an identifier for Indirect Coding.