Skip to main content
Question

How can I make a dynamic flexible status bar

  • December 24, 2025
  • 2 replies
  • 49 views

luispinto
AIMMSian
Forum|alt.badge.img+6

Hello!

 

I got an interesting question and thought it would be nice to share the answer here.

Question: How can I make a status bar that is dynamic/flexible in AIMMS?

This is how I tried it, but it didn't work:

StringParameter sp_fixedStatusBar {
IndexDomain: (webui::indexApplicationExtension,webui::indexStatusBarSpec);
Definition: {
data
{
( 1, icon ) : "aimms-glass" ,
( 1, color ) : "red" ,
( 1, text ) : "sp_context",
( 1, tooltip ) : "sp_statusTooltip" ,
( 1, procedure ) : "pr_toggleDeveloper",
( 1, state ) : "Active"
}
}
}

 

For those unfamiliar with the data { } construct, this may be a pitfall, since you imagine that the string parameter could be used like above - but it doesn't work that way.

This construct only allows you to add data - it doesn't cater for the dynamic/flexible part.

But there are two solutions.

 

Dynamic definition

Probably the simplest solution to this, is just to switch from the data { } construct to the { } construct, as below: 

 

StringParameter sp_dynamicStatusBar {
IndexDomain: (webui::indexApplicationExtension,webui::indexStatusBarSpec);
Definition: {
{
( '1', 'header' ) : "",
( '1', 'icon' ) : "aimms-glass",
( '1', 'color' ) : "red",
( '1', 'text' ) : sp_context,
( '1', 'tooltip' ) : sp_statusTooltip,
( '1', 'procedure' ) : "pr_toggleDeveloper",
( '1', 'state' ) : "Active"
}
}
}

Please note that:

  • You need now to place simple quotes around the elements you want to define the value
  • You need to remove the double quotes from the string parameters

This allows for the status bar to be flexible and updated automatically when values change.

 

Initial values or Procedure defined

The other solution is to not make the status bar string parameter defined. Either initialize it with the initial values option, or by a procedure that fills it out.

Like for the above, you could update the text via a procedure, like:

sp_dynamicStatusBar('1','text') := "My new text";

Please note that sp_dynamicStatusBar cannot be “defined” anymore, or else you will get an error.

You can download an example of this working in the Vessel Scheduling example: https://how-to.aimms.com/Articles/590/590-vessel-scheduling.html

 

Hope it helps!

2 replies

  • Explorer
  • March 5, 2026

Oh, I completely see your point of view. Making AIMMS status bars fully dynamic can be challenging. The key point is that anything that needs to change at runtime just won't work well in the `data { }` construct because it is static by design. The clearest option if you want modifications to spread automatically is to switch to the `{ }` dynamic definition.

One thing I typically do is combine that with a little update procedure; essentially, leave `sp_dynamicStatusBar` un-defined and simply push the new data via something like this whenever something changes (like context or status)."Updated text" is displayed in

``aimms 
sp_dynamicStatusBar('1','text'); "green" is displayed in
sp_dynamicStatusBar('1','color'); ```

In this manner, you can have the bar react in real time to events or procedure outputs without violating AIMMS regulations. Additionally, quoting the indices is crucial because AIMMS is particular about the difference between `'1'` and `1`. Although it's little, many people are bitten by it.

The general idea for any AIMMS webui status bar is to utilize quotes on indices, update via procedure, and consider **dynamic = no `data { }`. It's easy once you figure out that pattern.


Chris Kuip
AIMMSian
Forum|alt.badge.img+7
  • AIMMSian
  • March 19, 2026

Great technical summaries. To add to this, I think it’s worth looking at the architectural consequences of these two approaches (definitions vs. assignments).

Summary of the above
 

  • Luis' post enumerates available mechanics for a dynamic status bar
  • Hall's post focuses on procedural updates

Neither of them addresses model architecture implications


Scope

The status bar is part of a broader pattern in the AIMMS WebUI, similar mechanisms are available for:

  • Primary and secondary page actions,
  • Widget actions,
  • Item actions,
  • Workflow,
  • Menu,
  • Tooltips, and
  • Side panels.

For each of these ingredients of a UI, the same trade-off applies.


First consequence: application maintenance

Many projects I've seen have separate libraries for :

  • (Input) Obtaining input, and verifying data,
  • (Core) Solving the operations research problem at hand, 
  • (UI) Presenting and interacting with the end user, and
  • (Reporting) Presenting computed results.

In the Input, Core, and Reporting libraries, the state of the application is maintained. 
In the UI library, the interaction with the business user is structured.
Which actions a business user can take, depends on the state defined in the other libraries.

As an example: consider two parameters maintaining part of the state of the application:
- p_dataVerified,
- p_solutionObtained.
As long as p_dataVerified is 0; only the input pages are shown.
As long as p_solutionObtained is 0, the Reporting pages are not shown.

The definition of available pages is

  • Definitions: pull based (UI derives from the state of other libraries)
  • Assignments: push based (other libraries push info to UI)

When redesigning the UI, which libraries need to be maintained.  
When string parameter definitions are used in the UI libraries, then only the UI library needs to be maintained; when assignments are used - perhaps also other libraries need adapting.

Continuing the example, consider the extension of the UI with a status bar, whereby the optimum value, if available, is to be presented in the status bar as well.
When defined parameters are used, this change is only in the UI library.
When assignments are used, then the code in the other libraries will need to be added such that the status bar string parameter has the correct value.

Second consequence: efficiency

Consider a definition for a tooltip: sp_tooltip(i) = formatString( "….", d(i) ).

When a single element of d changes, the definition of sp_tooltip is re-evaluated for all i.
This only matters where:

  • large index domains
  • expensive string construction

Otherwise, it's negligible. For a status bar which has a small index domain, it is typically negligible.

Here:
Assignments → update only what you touch

Definitions → potentially recompute full domain
 

Conclusion


 Use definitions for UI consistency; use assignments only for high-frequency updates.


Didn't find what you were looking for? Try searching on our documentation pages:

AIMMS Developer & PRO | AIMMS How-To | AIMMS SC Navigator