Basically you need to think about TSPlus as a website/server. It sets itself up as a web server on your server. A user accesses your server via their browser. TSPlus can offer a login to the user which is tied to the servers / Windows user login system i.e. for each of your users you create a user account on the server with username/password. When the user logs into the server / TSPlus the application is loaded and run on the server in memory allocated to the users login. TSPlus now just shuttles the screen updates to the user and gets the users mouse interactions from the user. it all looks like the app is running locally on the user machine but it is really running on the server.

So now your app creates an XLSX file. It will need to be re-programmed so that instead of it opening directly in Excel (which does not exist on the server) it saves the XLSX file locally in the web accessible TSPlus folder and send the user a URL to that XLSX file. The users browser then downloads the XLSX file and opens it with the user's local Excel application. It is easier than it sounds :)

Printing is also very straight forward.

A person familiar with the setup routine, i.e. who has done it a few times, can get the whole thing up and running in 30 minutes or less. There are various options in TSPlus like being able to run apps without any login but we always use login since we charge per user and each user must have their own login.

Oh, thought of another issue which we had - you need to make sure that user specific files, e.g. user preferences and settings, are stored in user specific folders and not all in a generic folder such as on the local C: drive. The reason is that each user accessing your app will need to store their specific files separately from other users using the app which is running on the *same* server. To clarify - in a classic network environment I might have an app on the server storing user personal files on their local C: drives somewhere. This works fine in a classic network since every user has their own C: drive. But now all the users are actually running the app on the same server with the same C: drive! So if you store user files locally to C: drive then you need to make sure your app uses unique folder names for each user otherwise all the users will be using the same "local" C: drive files. I hope I have explained this properly.


>Jos,
>
>Thank for the detailed description of how to "get around" some "limitations" of using the TSPlus. I think both of your cases apply to my application. It does need creating XLSX files but this done without MS Office; it is done by using Greg Green's tools to export data to the Excel. And if I understand you correctly, the Excel file will be created on the TSPlus server then "sent" to the client PC.
>
>Also, my app prints all the time (orders, reports, etc.). So your approach - even though I don't yet understand how it works - will need to be used.
>
>I will watch the TSPlus videos and, hopefully, understand it better.
>
>Again, thank you.
>
>
>>Dmitry
>>
>>TSPlus works fantastically well and with zero changes to your VFP app except ... the only exception we found was this; our apps often integrate with MS Office using office automation to create XLS or DOC files on the user's computer. This cannot work over TSPlus because your app is running on the server and the MSOffice is installed on the user's computer. Problem!
>>
>>The solution is to create the XLS file on the server (using VFP and/or tools that create XLS files) and then store the XLS file to a local folder inside the TSPlus web folder, then create a URL to that XLS file, then tell the TSPlus to open the URL on the client side. What happens is that the URL is sent by TSPlus to the client to open and then the client's browser opens the URL which then downloads the XLS file from the server/TSPlus webs folder. Problem solved.
>>
>>The above requires two things (1) the above code changes, and (2) a clean-up routine to regularly clean-up these XLS/DOC files which your app might create once the user has downloaded them. We just delete any file which has not been accessed for 1 hour. This is an arbitrary timeout since the user will have accessed the file immediately when the URL got redirected to him. It is just a time delay to use in our clean-up routines.
>>
>>Of course, this is only necessary if your app integrates with MS Office.
>>
>>Another thing to be aware of; printing in TSPlus. How is this done since the app running on the server has no direct access to the printer connected to the user's computer. This is done by TSPlus capturing the print request and creating a PDF file of the report on the server . The PDF file is then sent to the user's computer for processing / printing by the TSPlus program on the client end. it is very seamless and very slick but you need to be aware that the report is not printed by VFP to a printer directly but rather to a PDF file which is then printed.
>>
>>
>>
>>
>>
>>>Good evening Denis,
>>>
>>>Thank you for your encouragement. And thank for offering to help. I appreciate it!
>>>
>>>>Hello Dmitry,
>>>>
>>>>It is very easy to use and 0 change needed to the VFP application,.
>>>>
>>>>Their videos are very clear. Jus try the demo. If you have a question I'll be happy to help as much as I can.
>>>>
>>>>Regards.
>>>>
>>>>>>
>>>>>>I already use TSPlus and now I see that I could probnably use that AlwaysUp for my personal needs but also suggest it to the I.T. director where I work. Who knows in what situation we would need that tool.
>>>>>>
>>>>>
>>>>>I am jealous. I lose a lot of business because prospective customers do not want to deal with hardware (building VM, etc). TSPlus would be perfect; I just keep putting of leaning it :(