which option is better,
RUN CLOUD VFOXPRO whitout without RDP
Get more with the least changes?....
RUN CLOUD VFOXPRO whitout without RDP
Get more with the least changes?....
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VFOXPRO IN CLOUD 3
- Thread starter avsalf
- Start date
-
1
- #2
Olaf Doschke
Programmer
As I've seen others here struggle with this and assuming they try to bring legacy VFP into the web, in short, that fails.
If your VFP base is at least Visual Foxpro, meaning it uses forms and not screens, it uses visual controls, and not @SAY and @GET, it uses object orientation and events, then FoxInCloud and Lianja may work for you, but nothing is as simple as RDP to apps running in their unchanged form. And there never will be anything simpler, because that really is just running things as is over remote access.
Bye, Olaf.
Olaf Doschke Software Engineering
If your VFP base is at least Visual Foxpro, meaning it uses forms and not screens, it uses visual controls, and not @SAY and @GET, it uses object orientation and events, then FoxInCloud and Lianja may work for you, but nothing is as simple as RDP to apps running in their unchanged form. And there never will be anything simpler, because that really is just running things as is over remote access.
Bye, Olaf.
Olaf Doschke Software Engineering
Olaf Doschke
Programmer
Maybe a bit more reasoning why I don't see legacy screens working in cloud solutions.
To start, as said, the converters I see (you may include vfp2iis) convert VFP to HTML and I can understand how someone with a legacy FoxPro application sees this as a chance to immediately modernize to HTML and may take the generated code for further development.
You expect too much
You have the two ends of a rope you'd like to knot together, the legacy code and the result you'd like to see in a web-based application. These ends have to connect, but they don't directly connect.
The real step from legacy code to VFP9 within the Foxpto platform is never really done. What I see is that people try to convert screens to forms and finally give up and rather keep their PRGs. That's mainly doing nothing, you only do the absolute necessary small correction using other fonts, turning off incompatible Themes and such minor things. You lose the ability to work visually on screens as VFP has no screen designer/editor which was replaced by class/form designers. The only similarity is they are still about the user interface.
So you're mainly just using the VFP9 runtime backward compatibility that is excellent and even supports commands not mentioned in the VFP help. You still have a lot of work to unbind this from Themes and get an acceptable look&feel, but actually you just did some of the work that is to be expected if you never wash dishes for 20 years and then try to cram all your accumulated dirty dishes into a single run of a dishwasher.
The other side of the conversion is, as I already said, going to HTML widgets, but you can't turn @SAYS directly into an HTML widget, the visual controls of forms can be converted, they work in a much more similar fashion as objects with properties, methods, events.
The solution could be first doing the essential missing step neither the VFP screen converters do nor the cloud converters can do on legacy Foxpro code.
And just think about why nobody really goes that intermediate step. It's the most expensive one, it takes the most effort and time as there is no easy automatable conversion. If it's complicated you better know just the design and thoughts put into functionalities and data structures and redo from scratch. And if you need to do that, you can actually go the route of new development.
Now feel free to contradict me in major points, but I don't see myself capable to do, I don't have the legacy knowledge. And the ones I know that have this is mainly Mike Lewis, some others who post rarely or may have retired. If you are the original developer that's okay, that would help a lot, but if you don't know the way Visual FoxPro differs from legacy FoxPro you have a steep learning curve even though the language is still FoxPro, there is a paradigm shift between screens and WinForms. I would, therefore, conclude once more, don't go that route, and instead take the steep learning curve of the web cloud done natively in HTML/CSS/JS with a Node.js based stack. All you have to learn to bring legacy Fox to VFP forms is halfway wasted, once this is converted to HTML you have yet to learn the HTML world to pick up on this and take it to the next and future proof level, then rather go there directly. The step is even less possible to do as any type of conversion, but you will redo all you have and learn what gives you a future for these apps and for yourself as a professional.
Bye, Olaf.
Olaf Doschke Software Engineering
To start, as said, the converters I see (you may include vfp2iis) convert VFP to HTML and I can understand how someone with a legacy FoxPro application sees this as a chance to immediately modernize to HTML and may take the generated code for further development.
You expect too much
You have the two ends of a rope you'd like to knot together, the legacy code and the result you'd like to see in a web-based application. These ends have to connect, but they don't directly connect.
The real step from legacy code to VFP9 within the Foxpto platform is never really done. What I see is that people try to convert screens to forms and finally give up and rather keep their PRGs. That's mainly doing nothing, you only do the absolute necessary small correction using other fonts, turning off incompatible Themes and such minor things. You lose the ability to work visually on screens as VFP has no screen designer/editor which was replaced by class/form designers. The only similarity is they are still about the user interface.
So you're mainly just using the VFP9 runtime backward compatibility that is excellent and even supports commands not mentioned in the VFP help. You still have a lot of work to unbind this from Themes and get an acceptable look&feel, but actually you just did some of the work that is to be expected if you never wash dishes for 20 years and then try to cram all your accumulated dirty dishes into a single run of a dishwasher.
The other side of the conversion is, as I already said, going to HTML widgets, but you can't turn @SAYS directly into an HTML widget, the visual controls of forms can be converted, they work in a much more similar fashion as objects with properties, methods, events.
The solution could be first doing the essential missing step neither the VFP screen converters do nor the cloud converters can do on legacy Foxpro code.
And just think about why nobody really goes that intermediate step. It's the most expensive one, it takes the most effort and time as there is no easy automatable conversion. If it's complicated you better know just the design and thoughts put into functionalities and data structures and redo from scratch. And if you need to do that, you can actually go the route of new development.
Now feel free to contradict me in major points, but I don't see myself capable to do, I don't have the legacy knowledge. And the ones I know that have this is mainly Mike Lewis, some others who post rarely or may have retired. If you are the original developer that's okay, that would help a lot, but if you don't know the way Visual FoxPro differs from legacy FoxPro you have a steep learning curve even though the language is still FoxPro, there is a paradigm shift between screens and WinForms. I would, therefore, conclude once more, don't go that route, and instead take the steep learning curve of the web cloud done natively in HTML/CSS/JS with a Node.js based stack. All you have to learn to bring legacy Fox to VFP forms is halfway wasted, once this is converted to HTML you have yet to learn the HTML world to pick up on this and take it to the next and future proof level, then rather go there directly. The step is even less possible to do as any type of conversion, but you will redo all you have and learn what gives you a future for these apps and for yourself as a professional.
Bye, Olaf.
Olaf Doschke Software Engineering
Take a look at TSPlus Enables you to run unmodified VFP in a hosting environment such as AWS, Azure, etc.
Similar to RDP but less costly. It has zero client install option. Apps can be run by any client with an HTML5+ browser.
Bill Chambers
Chambers & Associates
Similar to RDP but less costly. It has zero client install option. Apps can be run by any client with an HTML5+ browser.
Bill Chambers
Chambers & Associates
Nigel Gomm
Programmer
Bill,
TSPlus looks interesting. Are you using it in production?
nigel
TSPlus looks interesting. Are you using it in production?
nigel
Hi Nigel,
Using TSPlus for three VFP applications, in various stages of implementation.
One app is in use, another will go online for production within 30-60 days.
We are using the TSPlus mobile edition and their security add-on product, hosting via OVH.com, a dedicated server with Windows Server 2016.
Bill Chambers
Chambers & Associates
Using TSPlus for three VFP applications, in various stages of implementation.
One app is in use, another will go online for production within 30-60 days.
We are using the TSPlus mobile edition and their security add-on product, hosting via OVH.com, a dedicated server with Windows Server 2016.
Bill Chambers
Chambers & Associates
Nigel Gomm
Programmer
Thanks Bill,
I'm going to pursue this further just wanted to be sure it was stable, actively supported etc etc.
Any feeling for how concurrency compares with MS RDP; i.e. for any given windows server do you see it supporting a comparable number of active sessions?
n
I'm going to pursue this further just wanted to be sure it was stable, actively supported etc etc.
Any feeling for how concurrency compares with MS RDP; i.e. for any given windows server do you see it supporting a comparable number of active sessions?
n
Hi Nigel,
>>Any feeling for how concurrency compares with MS RDP; i.e. for any given windows server do you see it supporting a comparable number of active sessions?
Haven't benchmarked. Can't say.
Bill Chambers
Chambers & Associates
>>Any feeling for how concurrency compares with MS RDP; i.e. for any given windows server do you see it supporting a comparable number of active sessions?
Haven't benchmarked. Can't say.
Bill Chambers
Chambers & Associates
Olaf Doschke
Programmer
The resource need of concurrent sessions is limited from two sides: 1. What resources does the application need on the remote server per session, second what bandwidth is needed towards the clients. A TS software package can only reduce the bandwidth it needs.
You have to dimension the server to support as many sessions as you want to support in the first place before bandwidth can become the main restriction at all.
With a public audience for an app, that can become a problem. But if that's your goal we wouldn't even need to talk about whether some type of remoting works, you would not want to provide a legacy FoxPro app look&feel to a public audience. That's not just my personal opinion, I personally care more for function than for form, but you only get a large audience with a good UX.
Anyway, concentrating on technical aspects: Microsofts remote desktop protocol can make use of many accelerations depending on client capabilities, though. There are reasons why some terminal solutions have become brands and others not.
Bye, Olaf.
Olaf Doschke Software Engineering
You have to dimension the server to support as many sessions as you want to support in the first place before bandwidth can become the main restriction at all.
With a public audience for an app, that can become a problem. But if that's your goal we wouldn't even need to talk about whether some type of remoting works, you would not want to provide a legacy FoxPro app look&feel to a public audience. That's not just my personal opinion, I personally care more for function than for form, but you only get a large audience with a good UX.
Anyway, concentrating on technical aspects: Microsofts remote desktop protocol can make use of many accelerations depending on client capabilities, though. There are reasons why some terminal solutions have become brands and others not.
Bye, Olaf.
Olaf Doschke Software Engineering
Nigel Gomm
Programmer
Olaf,
i have an existing product with over 1.3 million lines of code and several hundred reports and documents (many of them customised for and by the specific user) so not easily replaced.
A web version is underway but is a while away still; meanwhile where i have customers without a windows desktop (increasingly common) RDP is the best way to get them using the product as is.
Problem is the MS RDP licences get expensive and is a cost i have to eat hence my interest in TSPlus. Currently have about 100 users using RDP and i just want to be sure that for any given RDP server TSPlus can support at least as many concurrent users as the MS product... otherwise what I save on RDP licences i may end up spending on hosting costs.
(Wine is not ready for production use and virtual box/parallels etc is fine if the customer already uses it but not something i want to be giving away or installing.)
n
i have an existing product with over 1.3 million lines of code and several hundred reports and documents (many of them customised for and by the specific user) so not easily replaced.
A web version is underway but is a while away still; meanwhile where i have customers without a windows desktop (increasingly common) RDP is the best way to get them using the product as is.
Problem is the MS RDP licences get expensive and is a cost i have to eat hence my interest in TSPlus. Currently have about 100 users using RDP and i just want to be sure that for any given RDP server TSPlus can support at least as many concurrent users as the MS product... otherwise what I save on RDP licences i may end up spending on hosting costs.
(Wine is not ready for production use and virtual box/parallels etc is fine if the customer already uses it but not something i want to be giving away or installing.)
n
Nigel,
You may want to post your TSPlus capacity question on LevelExtreme.com.
A few VFP/TSPlus developers with larger volume apps hang around there.
Bill Chambers
Chambers & Associates
You may want to post your TSPlus capacity question on LevelExtreme.com.
A few VFP/TSPlus developers with larger volume apps hang around there.
Bill Chambers
Chambers & Associates
- Thread starter
- #13
Thanks Bill
Enabling a VFP in a web environment under MS windows, AWS, or Azure is something that allows a technological step, while rewriting applications in .net, Phyton or JS. The bandwidth that fox uses is high so the data is in SQL and TSPLUS is just what I was looking for as a partial solution, as well as the support for printers without installing drivers on the server.
Enabling a VFP in a web environment under MS windows, AWS, or Azure is something that allows a technological step, while rewriting applications in .net, Phyton or JS. The bandwidth that fox uses is high so the data is in SQL and TSPLUS is just what I was looking for as a partial solution, as well as the support for printers without installing drivers on the server.
-
2
- #14
foxincloud
Vendor
Hi Avsalf,
If you're still interested, let me draw a comparison between TSplus, Lianja, West-wind and FoxInCloud.
TSplus works as a video replication between the VFP app running on the server and the animated image the user can see in the browser, using the [tt]<canvas>[/tt] HTML5 element. It requires that each user has his own app running on the server like what happens in RDP. In other words each user runs a separate copy of the app. You obviously need to learn and develop nothing more than implementing your app and the TSplus container on the server, and provision enough RAM and bandwidth to accommodate enough concurrent users. However users can see exactly the same VFP app. in the browser as they'd see on the desktop, you take no advantage of Web technologies like responsive design, CSS, animations, etc.
FoxInCloud goes one step further by dynamically building a HTML/CSS/JS/AJAX user interface out of the VFP forms of your app, using the whole scope of HTML, CSS and JS capabilities (elements such as [tt]<input>[/tt], [tt]<select>[/tt], [tt]<textarea>[/tt], CSS background, CSS animations, JavaScript event binding, AJAX requests, etc.); for layout, you can choose between classic (VFP-like), or responsive design (more modern look and adapts to any screen size); you can even customise your HTML/CSS/JS rendering. FoxInCloud implements the same events as you have in your desktop application (Click, Valid, etc.) and runs your app's code on the server when user triggers these events in the browser. FoxInCloud shares the application instance(s) between users; eg. 1 instance can serve up to 5 concurrent users. You need to adapt your app code using free tools (FAA) and, once adapted, you can deploy your single adapted code base either as a desktop or a Web application (just the projects differ). In terms of skills, you need to be fluent in Object-Oriented Programming, and be eager to learn from reading other's code. However you do most of the work in VFP and you'll write HTML/CSS/JS only for very fancy custom renderings.
Lianja also builds a Web application out of a 'desktop-like' design using standard blocks (aka panels) provided by Lianja. You can re-use bits of your VFP app code (eg. business objects) however you need to re-think your app. using the Lianja app design approach. You can also mix VFP code with other languages such as Python, a good opportunity to slide to another skill base.
West-Wind Web Connect compares to other mainstream Web development stacks (eg. PHP, python, ruby) by providing the bricks between a Web server and VFP code, plus a bunch of utilities to ease Web app. development. However you need to build every bits of your user interface (HTML, CSS, JS), and deeply understand how HTML, CSS, JS and HTTP work; and you need to write the server code, albeit in VFP, to respond to each user event, and manage the user state (know what a user has done so far when processing a new event). To make data binding easier, you'll probably want to use a client-side framework (Angular, View.js, etc.) however these extra layers of complexity require a very good understanding of JavaScript (similar to VFP on some aspects such as loose typing, a little more conceptual because of the full object orientation -- eg. functions and methods of objects are objects themselves, where the meaning of 'this' varies according to the execution context). Web Connect gives you the full freedom to build your Web application while securing your server-side development written in VFP, however the learning curve remains stiff (though less than if you chose to build a python or PHP-based Web app.)
If you're still interested, let me draw a comparison between TSplus, Lianja, West-wind and FoxInCloud.
TSplus works as a video replication between the VFP app running on the server and the animated image the user can see in the browser, using the [tt]<canvas>[/tt] HTML5 element. It requires that each user has his own app running on the server like what happens in RDP. In other words each user runs a separate copy of the app. You obviously need to learn and develop nothing more than implementing your app and the TSplus container on the server, and provision enough RAM and bandwidth to accommodate enough concurrent users. However users can see exactly the same VFP app. in the browser as they'd see on the desktop, you take no advantage of Web technologies like responsive design, CSS, animations, etc.
FoxInCloud goes one step further by dynamically building a HTML/CSS/JS/AJAX user interface out of the VFP forms of your app, using the whole scope of HTML, CSS and JS capabilities (elements such as [tt]<input>[/tt], [tt]<select>[/tt], [tt]<textarea>[/tt], CSS background, CSS animations, JavaScript event binding, AJAX requests, etc.); for layout, you can choose between classic (VFP-like), or responsive design (more modern look and adapts to any screen size); you can even customise your HTML/CSS/JS rendering. FoxInCloud implements the same events as you have in your desktop application (Click, Valid, etc.) and runs your app's code on the server when user triggers these events in the browser. FoxInCloud shares the application instance(s) between users; eg. 1 instance can serve up to 5 concurrent users. You need to adapt your app code using free tools (FAA) and, once adapted, you can deploy your single adapted code base either as a desktop or a Web application (just the projects differ). In terms of skills, you need to be fluent in Object-Oriented Programming, and be eager to learn from reading other's code. However you do most of the work in VFP and you'll write HTML/CSS/JS only for very fancy custom renderings.
Lianja also builds a Web application out of a 'desktop-like' design using standard blocks (aka panels) provided by Lianja. You can re-use bits of your VFP app code (eg. business objects) however you need to re-think your app. using the Lianja app design approach. You can also mix VFP code with other languages such as Python, a good opportunity to slide to another skill base.
West-Wind Web Connect compares to other mainstream Web development stacks (eg. PHP, python, ruby) by providing the bricks between a Web server and VFP code, plus a bunch of utilities to ease Web app. development. However you need to build every bits of your user interface (HTML, CSS, JS), and deeply understand how HTML, CSS, JS and HTTP work; and you need to write the server code, albeit in VFP, to respond to each user event, and manage the user state (know what a user has done so far when processing a new event). To make data binding easier, you'll probably want to use a client-side framework (Angular, View.js, etc.) however these extra layers of complexity require a very good understanding of JavaScript (similar to VFP on some aspects such as loose typing, a little more conceptual because of the full object orientation -- eg. functions and methods of objects are objects themselves, where the meaning of 'this' varies according to the execution context). Web Connect gives you the full freedom to build your Web application while securing your server-side development written in VFP, however the learning curve remains stiff (though less than if you chose to build a python or PHP-based Web app.)
You might want to check me on this; one of the advantages of RDP on a Windows server (now known as RDS - Remote Desktop Services) is that after the fist user logs on and opens the EXE file for a program, RDS caches that EXE so that subsequent users don't need as much RAM to run it. For example, on a Server 2008 R2 that I have open now, there are a few users running a VFP app (EXE) and the RAM usage shows one user using 101K, and the second user is using 39K, and the third user is using 41K of RAM. My point is that MS has done a good job with RDS in how it uses resources and that may be factor in your decision when it comes to server-side costs.
Bill
Bill
- Thread starter
- #16
Interesting comparison between TSplus, Lianja, West-wind and FoxInCloud,Thank you.
I'm going to download the demo ( and do a test, I think I can combine, some clients that use only a part of my application make these changes with FoxInCloud and the clients that use all the functions with Tsplus or Rds, according to how you see the advance with FoxInCloud the idea would be to move everything to this scheme! 17,274 SCX make up the entire application.
I am concerned that we have some components like foxpreview to generate PDF and com controls like TreeView, WinHttp.WinHttpRequest.5.1, Outlook.Application and excel.Application I don't know if these can be worked with office 365 or google Docs
Thanks
I'm going to download the demo ( and do a test, I think I can combine, some clients that use only a part of my application make these changes with FoxInCloud and the clients that use all the functions with Tsplus or Rds, according to how you see the advance with FoxInCloud the idea would be to move everything to this scheme! 17,274 SCX make up the entire application.
I am concerned that we have some components like foxpreview to generate PDF and com controls like TreeView, WinHttp.WinHttpRequest.5.1, Outlook.Application and excel.Application I don't know if these can be worked with office 365 or google Docs
Thanks
foxincloud
Vendor
avsalf said:
You can adapt your application by parts, with sub-projects containing the forms of a functional area.
Once you've adapted your classes for the first project, then the other projects inherit from them.
An important point: you adapt the same source code that you deploy for desktop / RDP / TSplus; you have a single code base for both Web and desktop deployment.
avsalf said:
That's really huge… the largest project we've worked with was 1/10th of that…
you definitely need sub-projects that you'll deploy in separate sub-domains such as dom1.yourcompany.com, dom2.yourcompany.com, etc. (your company or your clients' company)
[ul]avsalf said:
[li]foxpreview to generate PDF: supported [/li]
[li]TreeView: supported [/li]
[li]WinHttp.WinHttpRequest.5.1: supported[/li]
[/ul]
avsalf said:
Although Microsoft discourages automating Office components on a server (mainly because it's licensed per machine and any number of users can use a Web server), you can do some Office automation from a FoxInCloud Web Application
Olaf Doschke
Programmer
afsalv said:
That is an impressive number. The question is, whether these are legacy screens or VFP forms. I guess we'll soon see.
Bye, Olaf.
Olaf Doschke Software Engineering
Koen Piller
Programmer
avsalf said:
I have a feeling we are talking about the size and not the number. A scx of 17KB is not so big.
Stay healthy,
Koen
Olaf Doschke
Programmer
After Nigel talked of legacy applications with 1.3 million lines of code I wouldn't be surprised by over 17 thousand screens. I bet some of them are generated and only have nuances of differences. I think with OOP programming you could reduce this to far less forms classes with inheritance.
Anyway, avsalf could easily state more clearly, if he only meant one screen that size or that many screens. I share a bit of your disbelief in as many forms, but another perspective about that is: A single form application could easily be redone manually, over 17 thousand screens are surely a reason to look for automatic conversion.
I doubt FoxInCloud can convert them., as an SCX file is something different in a legacy project than in a VFP project, but they could tell something about that, as this may not be the first try of someone with a legacy project to use FoxInCloud. Maybe they also convert legacy SCX.
In both legacy and Visual foxPro an SCX is a DBF, but it has different structure and content and meaning. In legacy Foxporo an SCX compares to definition data analogous to what we still know for menus, when you compile screens they are processed to a PRG via genscreen,genscreenx or scx2prg, like a menu definition table is processed to a menu prg MPR with genmenu.
A Visual FoxPro SCX form is a form that is not preprocessed, it is run as-is. That's why I earlier said I think you can't skip the conversion from legacy to modern FoxPro with FoxInCloud, but we'll also see that.
Bye, Olaf.
Olaf Doschke Software Engineering
Anyway, avsalf could easily state more clearly, if he only meant one screen that size or that many screens. I share a bit of your disbelief in as many forms, but another perspective about that is: A single form application could easily be redone manually, over 17 thousand screens are surely a reason to look for automatic conversion.
I doubt FoxInCloud can convert them., as an SCX file is something different in a legacy project than in a VFP project, but they could tell something about that, as this may not be the first try of someone with a legacy project to use FoxInCloud. Maybe they also convert legacy SCX.
In both legacy and Visual foxPro an SCX is a DBF, but it has different structure and content and meaning. In legacy Foxporo an SCX compares to definition data analogous to what we still know for menus, when you compile screens they are processed to a PRG via genscreen,genscreenx or scx2prg, like a menu definition table is processed to a menu prg MPR with genmenu.
A Visual FoxPro SCX form is a form that is not preprocessed, it is run as-is. That's why I earlier said I think you can't skip the conversion from legacy to modern FoxPro with FoxInCloud, but we'll also see that.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
- Locked
- Question
