rc002017

Thanks, will repeat tests during peak and off peak times using compression and report back. Rob

and... Thanks Patmap and Farshad. I have now tested the original multi-panel app and the blank form app as suggested by Farshad. Neither had compression enabled as suggested by Patmap. Test 1 - loaded in browser running on web server : blank form loads in max 1 sec, multi panel app loads in 3 secs. Test 2 - loaded in browser on pc on same LAN as web server : results same as Test 1. Test 3 - connected via VPN over DSL line during off peak periods : blank form loads in 2 secs, multi-panel app loads in 4-6 secs. In Test 3 scenario there was no difference when I disabled firewall and anti-virus etc on calling pc, response measured with stopwatch was the same. However I noticed that if I closed the app with a "close" button on the form, and then clicked the "Restart Application" link generated by Unigui and placed in the browser, it could take upwards of 3 minutes to reload the app. It was better to close the browser window and call the link again from start. Network traffic on a 10/100 network card on pc (not server) in test 3 was less than 1% (using windows task manager networking monitor), and the source sent to the pc browser for the multi panel app amounted to 31kb when saved to a text file. This is impressive and indicates Unigui does not generate large overhead when sending forms to a browser, considering the dll is 3mb in size. Conclusions : DSL link I was testing on last week was heavily overused, causing slow responses. This could be a downside for Unigui apps as opposed to splitting the app up into a number of smaller html/php etc files, each of which may perform better over a heavily used link. In my opinion network and server design will have to be carefully designed to accommodate larger Unigui apps, as long startup times may affect user perceptions. The performance once up and running due to AJAX is of course one of the big pluses for Unigui apps. Regards Rob

Hello What is the recommended method of developing a Unigui app for performance ? I am developing a test app which has multiple panels and buttons, and a page control. Depending on which button is clicked the corresponding panel is set to visible=true, and the others are set to visible=false. Each panel has data controls embedded in them, with one panel containing the page control, which in turn has 6-7 tabbed pages. This amounts to a busy form, and the compiled size of the dll is approx 3mb - without all the functionality and data calls implemented. Performance when running and retrieving data from the back end MSSQL database is very good, however I have a concern about the intial loading time of the dll when called from the web browser. On a local LAN this can be reasonably slow (10-20 seconds) running under IIS 7 on Windows 2008, I presume this is due to the caching time taken by IIS. My main concern is for remote connections. If I connect remotely via a VPN over a DSL line it can take up to 5 minutes for the form to be displayed. This may well be due to heavy traffic on the link, but would the amount of html/javascript/ajax/css etc code generated by Unigui that has to be sent down the line to the browser be a factor in this ? Would it be better then to architect the app as separate, smaller dll's for each panel, and call them as needed, in much the same way as a traditionalweb app calling a.php, b.php, c.php, back to a.php, b.php etc ? I still need to test in off-peak periods to verify whether the dsl link traffic is the issue, but would appreciate comments and suggestions. Thanks.

Thanks, missed that one ! Works well, however there seems to be a problem changing the theme with source originally created with version 0.85. I am now using 0.86, and when I change the theme of the code created under 0.85 from blue to gray it does not change the page control theme, it remains blue in the web browser. If I create a new page control using 0.86, then change the theme it works perfectly. Not worried about this for now, but will the same problem be apparent moving from say 0.86 to 0.90, or a 1.0 release version ? Thanks.

Thanks Farshad. Looking in the css directory of the UniGui components I see a number of different css theme files. How do I change the UniGui setting in my app so I can use a different css theme for each app ?

Thanks Amit, changes the colour of the pages, but the tabs themselves remain the default light blue, something I wish to change as well. Is there a way to use a modified CSS theme that I can set to the colour scheme I wish to use ?

How do I change the colour of a Page Control (or any other component) which does not have a colour property ? I have a Page Control on top of a Panel, I can set the panel color property and it shows correctly in a browser, but the page control always shows the default light blue. Page control is ok when run as a standalon VCL app. This may mean I need to change themes but I am unsure of how to do this. Using v0.86 Thanks

Thanks Farshad, understood. Using the navigator solved the problem ! PS Good work on the component set, really excellent !

Sorry, not entirely clear, should read "If I try to set the PageSize at run time based on record count, and then hook up the datasource to the query, it does not display all rows retrieved, only the same number of rows as the PageSize setting prior to changing at run time i.e. used design time setting."

Thanks Farshad. I have run a test with the PageSize set (at design time) to just above the expected number of rows to be retrieved by the ADO query, and all rows are now displayed in UniDBGrid i.e. set PageSize to 250, ado query retrieves 200 rows, all rows displayed. ADO query cache set to 100. If I try to set the PageSize at run time based on record count, and then hook up the datasource to the query, it does not display all rows retrieved, only the same number of rows as the PageSize. I also set the ado query cache to 250, but only the amount of rows as per PageSize are displayed in the grid. In both instances the PageSize was set to 50, Paged=true. Perhaps this is something to do with the ADO component(s) ? Is this problem evident with other database access components ?

The grid is paged, I set it to 100 pages and now more rows are displayed. Seems to solve the problem, thanks. Is there a guideline for estimating the number of pages needed, especially at run time, based on the number of rows retrieved ?

I am writing a simple VCL/Standalone/Isapi app that retrieves rows from a SQL Server database as a test. The rows are displayed in a UniDBGrid. When I run it in as a normal Windows app, the grid is populated with say 200 records, and the ADO Query RecordCount is 200. If I now run it as an ISapi DLL and connect using Firefox or IE, the same ADO Query only returns approx 30-40 records to the UniDBGrid. However the ADO Query RecordCount is still 200. Any suggestions on where I am going wrong ? Thanks