One of my clients exclusively uses the web interface of Priority; whilst this is the face of the future, it's also more expensive as every user needs a licence (the classic Windows interface allows concurrent licences). I find the user interface much more difficult to work with (there are some items that I use frequently in the classic interface that I have yet to find in the web interface) but this is no doubt a function of habit. Upkeep and maintenance is probably less with the web interface as one can have one's database(s) hosted on another company's computer, thus one does not have to purchase and maintain servers. This is good for new companies but less good for existing companies.
But I digress. Unfortunately it often happens that I develop a report that I know will work with the classic interface but causes the web interface to crash. I was able to identify one cause of this behaviour that I am going to describe here.
In a report, one can define that certain fields will appear in a header line. In the classic interface, one can define however many fields as necessary to appear in the header, and the web browser that displays the report will automatically split the fields over two lines if the total width of the header exceeds the width of the report. Thinking about this, this probably occurs in the Priority procedure that takes the data, reads the report interface and creates the HTML code.
This does not happen with the web interface! Should a report have a header that is too wide, the feared error message will appear. The solution of course is very simple: one has to manually move the surplus fields to a second header line instead of having this occur automatically. Naturally this is not documented: it was only by observing what happened to a report with many fields in its header did I understand what was triggering the bug.
No comments:
Post a Comment