sgagn0 wrote:No, columns did not adjust to the width I specified. I took the code sample from the link i provided in the first post. I thought it was already useable.
Most likely, the guy who wrote that just copy/pasted the data sent from one of our 'data url' programs without checking to see that all of the fields were used. I know that our server-side programs were upgraded to output the column widths, but the client-side code that draws the screens did not use them last time I checked. (Which was a few months ago... but your tests prove that this has not changed.)
sgagn0 wrote:Yes, I would like to control the formatting from the server side (cgi program). Almost the same way I would control attributes in the RPG program that render the page, except that I would set the attribute value directly instead of going through a variable.
Unfortunately, it doesn't work that way right now. What happens is the screen definition (including all of the column formatting info) is loaded from your DDS by the handler. The handler sends this info to the screen, along with the RPG variables, and the PUI Framework (JavaScript code on the PC) draws the screen from that information. This results in a whole screen, including the grid -- but the grid is empty. After the screen is drawn, it then runs your data URL to get the data that's loaded into the (already drawn) grid.
sgagn0 wrote:This would mostly be used to change number of rows that are displayed, but would also be nice to be able to manage other attributes (column headings, visbility, etc).
The easiest way to do this is to use the tradional RPG manner of loading a subfile instead of a data URL. The user keys in data and clicks a button, and control goes back to the RPG program. It then does the search, and uses the WRITE opcode to load the subfile with the results. At the same time, it can control the formatting using fields that are bound to the properties of the grid. This is the way the tool is designed to be used, and is quite simple.
It's possible to do this sort of thing in other ways, but it will be more complicated. If you wish to use the 'data url' approach, the data url cannot control the formatting, but you can insert JavaScript code into the screen that will do so.
Or (this is so complicated that I'm not sure I want to suggest it) you could eliminate the Open Access handler, and build your screens dynamically by having RPG/CGI programs that output JSON data defining the screen. But, I wouldn't recommend this -- you're throwing away a lot of the value of using PUI in this case, and making things much more complicated and hard to maintain.
sgagn0 wrote:My current issue is to change # of rows so that all records (no paging) are displayed when doing a customer search.
Yes, so I'd recommend doing it the traditional RPG way. Load the subfile in the program, bind a field to the number of rows and set it to the number you've read via SQL. Or, alternately, write a little bit of JavaScript code that sets the number of rows during the 'onload' event for the screen.