I don't know if this would be applicable to your case, but you might consider using the Report Writer as it can create HTML output.

For more information on Calculated Fields, see:

https://manual.pvxplus.com/page/Report%20Writer/Designing%20a%20Report/Defining%20the%20Data/Calculated%20Fields.htm

Or check out the new training manual at:
https://home.pvxplus.com/files/7068/Introduction_to_PxPlus_-_A_Hands-On_Training_Guide_for_Developers.pdf
and search for 'calculated fields', or go to page 218.

Suriakumar,
There are two types of calculated fields:

• Formula - Contains a PxPlus expression that will be evaluated when the report is being generated. You can then define a Filter that will use the calculated field in its condition. For example, you could create a calculated field TOTALCOST that calculates COST+TAXES which can then be displayed on your report. Or you could define a Filter to only display the records where, for example, TOTALCOST > 1000. Or you could use it to set up different Cell or Line displays.
• Translation - This allows you to specify several conditions which will determine what is displayed on the report. For example, you could create a translation called MyMessage where the condition BALANCE>0 returns "Balance Due" and the Default returns "Paid".

SURIAKUMAR,
The code you show is for adding parameters dynamically at run-time when the report is being generated. They exist while the report is generated and are not being saved.
My question is this: Are the parameters required for the report always the same? That is, are you always requesting the COMPANY in this case. If so, you would define that as a parameter in the report definition using the Report Designer. See the Data > Parameter menu item.:
https://manual.pvxplus.com/PXPLUS/Report%20Writer/Designing%20a%20Report/Defining%20the%20Data/Parameters.htm

After you have defined your parameter here it will appear in the data pane of the Report Designer, where you can include it in the report, or use it in filters, etc.

At run-time when you are generating the report, if you generate it using the CALL method with the runreport program, it will automatically display an interactive panel to enter a value for the parameter. If you want to enter the value programmatically, after you open the report you can use the 'SetParameter(parmName$,value$) method to set the value, where parmName$ is the name you gave the parameter and value$ is the value to be assigned for the report.

The input source can be any native PxPlus file with an embedded data dictionary, a PxPlus View, a Query Definition, or any other data source whose data can be accessed using a Custom Data Source Object. External databases, such as ODBC, Oracle or DB2, can also be accessed via Views or Data Dictionary defintions. So if you are not using a Data Dictionary, you could create a manual query to supply the data or a report writer Custom Data Source Object to supply the data.

The Report Writer does not have global variables and functions like *web/start_up. You pass values into the Report Writer using parameters.
If you are running a report interactively, you can use the default interactive parameter interface to enter parameter values. If the report is not interactive, you can enter the parameter values programmatically using the 'AcceptParameters() method.

Here's a sample non-nomads program that creates a grid with cells that use a calendar query:
 
PRINT 'CS',
  mygrid=1000
  GRID mygrid,@(20,12,40,10)
  mygrid'columnswide=3,mygrid'rowshigh=5
  mygrid'row=0
  mygrid'colno=0,mygrid'columnwidth=10
  mygrid'colno=1,mygrid'celltype$="lookup" ! can edit cell
  mygrid'colno=2,mygrid'celltype$="query" ! cannot edit cell
  WHILE 1
  OBTAIN (0,SIZ=1)'ME',*,'MN'
  IF CTL=-1999 OR CTL=4 \
  THEN BREAK ! X or ESC
  IF CTL=mygrid \
  THEN GRID READ mygrid,mycol,myrow,myVal$,myEOM$;
        IF mycol<3 AND myEOM$=$FF$ \
        THEN GOSUB Do_Calendar \
        ELSE MSGBOX myVal$,"Value" ! the EOM for the lookup/query button is $FF$
  WEND
  END
!
Do_Calendar:
  PROCESS "Calendar","*win/calendar.en",myVal$
  GRID LOAD mygrid,mycol,myrow,myVal$+SEP
  RETURN

To HIDE/SHOW something on a panel, I find it easy to use Dependency Definitions:
https://manual.pvxplus.com/page/NOMADS%20Graphical%20Application/Panel%20Designer/Options%20and%20Utilities/Dependency%20Definitions.htm
A dependency definition will hide/show controls automatically based on a condition.
Note: To use a Dependency for fonted text you would first have to assign it to a group, and hide the group.

Yes. In the grid presets set the Property to 'Query", set your Column and Row to specify the cells to be affected, and click the query button in the Value/Expression cell  to set the Query Display. The Query Type would be Panel, the library would be *win/calendar.* and the panel would be CALENDAR.

Yes, you can use static filters and parameters to set up the range. The report generating logic will analyze the key segment fields against the key fields used in the static filters to see if a reading range can be set up.

Mike,
I'm not sure I follow. If the 'Multiple Selections' attribute is set for the list box, then all the rows selected will be highlighted automatically. (See example below.)

By default, list boxes require double clicks or Enter to select something. If it is doing a selection on a single click, then the Automatic (Signal all changes) attribute is set. You can filter as James suggested, where the single click is $01$.

An issue where Library Default FG/BG colors are not used in sub-panels has been reported and fixed for the next release.

We'll look into it.

Martin,
I have responded to your ticket with a possible fix, but have not heard back from you. I just wanted to check with you since previously you did not receive the auto ticket response.

You can set up a Linus SVN server as Mike described earlier. That is where the repository would reside.

As for the clients using the repository on the server, each client would have their own sandbox on their own Windows machine. Each client would install the Tortoise SVN client on their Windows machine, as well as PxPLus and their application. This is where they would do their development. When the administrator completes this, they would import the application into the repository. The rest of the clients would then checkout the source from the repository.

So all development is done on each developer's own machine, then committed to the repository when done, where other developers can update their source/app directories from there. Since each developer has their own work area on their Windows computer, this is not really a WindX style set up.