Norm

You should still be getting a response of some kind from the browser. Can you share that? Do you mind sharing the url so we can try to help with the diagnoses.

What you should do is the app in Chrome and check for errors in the Console tab of DevTools (F12). That should tell you what's breaking down.

Davie, just so you understand, Irigsoft’s suggestion is a good solution but it answers a different question, which is: How to detect that the browser is alive but idle because the user is not doing anything. Depending on what your app is for this might be an issue you’ll need to address at some point.

The SessionTimeout is an integer property in the ServerModule that you can set to any value. Here is a simple solution I use: First of all I set a SessionTime value at a low value (e.g. 2 minutes) and I set the uniTimer value at in the Main form, at say 30 seconds. I also create a boolean variable called "ImStillAlive" in the MainModule and set it to True at the start of the session. When the UniMainModuleSessionTimeout event fires in the MainModule I check whether the flag "ImStillAlive" flag is true or false. If the flag is true I extend the SessionTimeout by another 2 minutes and set the ImStillAlive flag to false. If the flag has not been reset to true next time the UniMainModuleSessionTimeout event fires I do nothing and let the session die. Meanwhile the Main form has the responsibility to always reset the ImStillAlive flag to True whenever the uniTimer fires (every 30 secs). If the browser dies the uniTimer will no longer fire and the session will die next time the UniMainModuleSessionTimeout fires. Simple but reliable. The UniMainModuleSessionTimeout procedure looks like this: procedure TdmDB.UniGUIMainModuleSessionTimeout(ASession: TObject; var ExtendTimeOut: Integer); begin if bImStillAlive then begin ExtendTimeOut := iMySessionTimeOut; (e.g. 2minutes) bImStillAlive := false; end else //Here we let the session die. So do all the cleanup necessary CleaUpThings; //Call a procedure to do some cleanup end; Something important you should know: Whenever the uniTimer fires it restarts the SessionTimeOut count in the ServerModule. So if your uniTimer is permanently enabled and it has an interval value that is lower then the SessionTimeout value then the session will never expire as long as the browser is active. The reason I use the above strategy is because whenever the uniTimer fires I momentarily stop the timer while I do whatever function I created the timer for and then I restart it on completion.

Davie, If the browser is not functioning the session will be automatically terminated after a short interval and the mainform will be killed. So there is nothing you need to do to make sure the session is killed if the browser if not working or the laptop has gone to sleep.

Hi Eric, Putting the Safari issue aside, I looked at your project and tried to understand what you are trying to achieve.

Hi John I might be interested in the project. Please supply you email address and I'll get in touch to introduce myself and ask you some questions regarding aspects of the project.

I provided an alternative javascript based FileUpload function that you can modify to achieve what you are after. E.g. you can monitor the rate of upload or set a timeout for the upload and abort the upload on timeout. Have a look at the thread and let me know if you need further help. I suggest you start by downloading and examining the last project I uploaded on the thread.

I’ll send you an example of each.

It depends on the type of data you are talking about. You can either use Ajax to send the data into your form or you can use Axios fetch to store the data into a local file that you can access with Delphi.

Please provide a simple example of how you loaded the data into the URLFrame and I’ll give you a solution.

I used the term Global Variables because that is what Fabio used. In my case these were session related private fields residing in a Data Module and accessed as public properties (getters / setters). I found that after I moved my application to IIS the field values were not retained properly. As I said I resolved the issue by moving the fields to the MainModule.

FYI I had exactly the same issue, global variables stored in a unigui data module working as expected but failing when I switched to IIS. I resolved the issue by storing the variables in the MainModule instead.

I suggest you look at this http://forums.unigui.com/index.php?/topic/18750-does-an-extension-of-the-unigui-license-makes-sense-at-all/&do=findComment&comment=106094

Your question is a very valid and logical one. The reason we are using UniGUI is because it allows us to bring over our large volume of legacy code with little change. Our area of software development is in the financials field. We have invested a lot of money and time in developing what I call a Financial Accounting Engine that we now use in all our projects. I designed the software over ten years ago and contracted some Delphi experts to help with the coding. We chose the DBISAM SQL database for our product instead of the Borland BDE because it is written in Delphi and has many hooks that allowed us to design our own middleware to address things like providing a JSON based API that allowed third-party products to interface with our financial system. When we started looking at web access we seriously looked at TMS WebCore and XDATA as a potential pathway but it had too many unknowns and the effort required for the conversion was unsustainable. I am very happy with the UniGUI solution we have implemented in spite of the shortcomings I mentioned in my previous post. To give you an idea of the kinds of projects we work on we have implemented a financial system for Wholesale Bakers that supply products to cafes and restaurants (bread, bagels, croissants etc). Before the end of each day the owners use our PWA app on their devices to place orders for the next day. At the end of the day the system generates and dispatches invoices for the ordered goods and provides the baker with reports listing both the quantities of each product and recipe measurements of ingredients required for each product category (flour, yeast, sugar etc).