Thursday, 26 July 2012

How to call a Linx Process and store a return value in variable

Stadium allows you to call a Linx process and with the latest release, it gets one step  better! The values returned by a Linx process can be used within Stadium.

Scenario : Set field property in DetailsView to ReadOnly based on value returned from Linx process

Set up a Linx process that returns Boolean value = True.

In Stadium Designer, set up a page with a Button and DetailsView.

In the button Click event, add a variable called linxvar.

Then, add CallLinxProcess action the ‘Click’ event of the button.
CallLinxProcess action has a ‘Parameters’ property. This property allows you to assign Input and output parameters. In this scenario, the Linx process contains one output parameter.

Set the parameter as follows:
  • Parameter Source :  None
  • Name : Boolean1 (Use the same name as Linx Output variable)
  • OutputToVariable : linxvar (name of the variable which was assigned in Click event)
  • Type : Boolean (Same type as Linx Output variable)

In this scenario, we are using the return variable to set a field in DetailsView to ReadOnly. To do that, add a SetControlProperties event after CallLinxProcess. Set the field ReadOnly value to linxvar variable.

You can now view the page in Internet Explorer. When you click on the Button, the Linx process will be called.

In Summary, you can call a Linx process; store the return value in a variable, then use the variable to set properties or as an input to other processes. However, take note of the following rules:
  1. The variable name defined in CallLinxProcess parameters property MUST be the same as the variable name in Linx.
  2. Linx allows Input and Output variable to have the same name but Stadium does not. So, if you want to link a Linx process in Stadium, ensure that the variable names are different.

Stadium Datagrid Visual Design Considerations

In Stadium 4, we’ve made a few visual changes to datagrids, including more whitespace. Whitespace or “negative space” is the space between and around elements in a graphic composition. The price we’ve paid is that datagrids now occupy a little more screen real estate than they did in the past. What we win is friendlier, less cluttered and more elegant data presentation.

Stadium is our rapid application development (RAD) tool. Our vision with Stadium is to simplify business application development as much as we possibly can. We want to make business people’s lives easier. At the same time, we have to consider the needs of the end-users of those (rapidly developed) web apps and try to make their lives easier too!

Existing Stadium apps address the needs of banks and investment managers, who typically process massive amounts of transactional data daily. The users of these applications often work in Dilbertesque, cubicle office environments under a great deal of pressure. The tasks they perform are generally routine batch processes that need to be completed within very strict timeframes.

For example, a user will import a few thousand transactions, run a validation check on all of them, export exceptions to one system and back up data to another. In this case, the user is notified of task completion by some kind of message (e.g. “Import completed successfully!”) and has little interest in individual record details.

Another kind of task involves individual records, such as data maintenance tasks. In this case, the user needs to find a specific record. He filters the data according to some known criteria and then he scans the filtered data until he somehow recognises the record he’s looking for.

Data in Stadium is presented to users in tables we call datagrids. It is extremely important that the information displayed to users is legible and easy to scan. We also want the data to be presented in such a way that it conveys a sense of order and calm. In addition to this, Stadium clients demand that their brands should be communicated by using very specific colour palettes.

How does one visually design a datagrid so that the information it displays:
  • is legible,
  • is easy to scan,
  • conveys a sense of order and calm and
  • conforms to client branding rules?
The short answer is: apply the principles of information design (and then refine).

Here’s the slightly longer answer.

We want to show as much data in as small a space as possible, without compromising on the other aspects. To convey a sense of order and calm, we tried to strive for as much visual consistency in our Stadium output apps as possible.

A surprisingly large proportion of our current end-users are stuck with older versions of IE and Windows. We decided to stick with Verdana as our default typeface, as it is one of the handful of typefaces guaranteed to display consistently across (older) browsers and operating systems, and was designed to be readable at small sizes.

The datagrid row height in Stadium 3 was 23px by default:

We thought this looked a little crowded and busy, with the congestion increasing when dropdowns or datepickers were added to grid, and increased the line height:

The additional whitespace adds some breathing room to the design. Dropdowns, textboxes and datepickers can be added into the datagrid and ample padding remains. For example, if we added a dropdown and a datepicker column into the datagrid, the datagrid’s rows needn’t stretch and some space remains between the controls and the grid lines:

For clients with very specific brand colours, the datagrid appearance can be changed to the desired theme. For example, the above datagrid in our Scarlet theme looks like this:

Information design is not an exact science. It is a field of study that aims to discover how we can make data easier to use and to interpret. It aims to derive principles we can apply in different use cases and scenarios, making the data under those unique circumstances more useful, and in so doing to add value to people’s lives.

It’s a process of optimisation where we strive to improve upon our existing designs within a framework of constraints. While we know that users will have to scroll more in certain cases, the new visual design lends itself out to more consistency and is tidier and more elegant.

Let us know what you think.

Stadium4 Release : 4.1.2144.4793

Build 4.1.2144.4793 is available for download. It includes:
  • Added paging on manage users screen
  • Filtering on manage users screen
  • New File->Generate Stats File menu item in designer
  • CallLinxAction can now store return values in variables
  • Button - New Visible property
  • Filter - New Visible property
  • DataGrid field editor - Changed behaviour of 'Refresh' toolbar button, it now only adds unmapped columns
  • DetailsView field editor - Changed behaviour of 'Refresh' toolbar button, it now only adds unmapped fields
  • HeaderText property in Stadium designer now defaults to 'Stadium'
  • Burgundy theme is no more, instead we have a new  'Scarlet' theme and colour scheme has been changed
  • Filter control has new 'Title' property
  • Fix for custom setting not working when used in queries
  • Fix for user unable to login if password has special characters
  • Fixed several panel display issues
Note: All sap files will need to be opened in designer and upgraded to latest version.

Stadium3 Release : 3.3.1993.4402

Build 3.3.1993.4402 is available for download. It includes:
  • Added paging on manage users screen
  • Filtering on manage users screen
  • New File->Generate Stats File menu item in designer
  • Fix for custom setting not working when used in queries
  • Fix for user unable to login if password has special characters

Wednesday, 25 July 2012

How to call a Stored Procedure and store a return value in a variable

In Stadium, it is possible to call stored procedures which return output values, and in turn display these output values in controls.

Scenario: Calculate Currency amount based on Exchange Rate

User enters Amount and Exchange Rate, and then clicks on the Calculate button. A calculated amount is displayed in a Label.

Steps :

Create a DetailsView with 2 Fields – Amount and Exchange Rate. Add a Calculate button and a Label called CalculatedValueLabel. DetailsView will be used to pass input values and Label will be used to display output values.

To the button Click event, add a variable (I named it calculateVariable).

Add ‘ExecuteSQLCommand’ event to the button.

Select a SQL connection in the Connection property. In the CommandDetails property, choose the Stored Procedure you want to connect to. Click on Refresh Parameters button. Parameters that are in the Stored Procedure are added automatically in Stadium.

In this example, there are 2 Input Parameters (value and exchangeValue) and 1 Output Parameter (calculatedValue).

Input parameter settings :

Assign the DetailsView field value to the Input Parameters (value and exchangeValue) using ‘Control’ Parameter Source.

Output parameter settings:

Set Parameter source for Output Parameter (calculatedValue) to ‘Output to Variable’. Select the output variable from OutputToVariable dropdown list. Type value can be selected from Boolean, DateTime, Int and String depending on the type of data you want to display.

Add SetControlProperties event after the ExecuteSQLCommand event. SetControlProperties event can be used to assign the variable value to other controls. In this example, we will be assigning it to a Label control.

Check on the Label. Select the variable that is used to store the output values (calculateVariable) as Text value.

Other Controls that can display values from Variables are :
  • DetailsView
  • DataGrid
  • TextBox
In a more advanced usage, it can be used as an Input to other processes such as CallLinxProcess or passed to events within the same Click event such as DisplayMessageBox or Decision.

In summary, users can call a Stored Procedure, pass values to the Input Parameters and display results received from the Output parameter.
  1. A Stadium control passes input values to Stored Procedure
  2. Stored Procedure does the Calculation, then passes the result to a Stadium control
  3. Stadium Control saves the results to a variable to be used when needed.