VFOXPRO IN CLOUD 3

[avsalf]

which option is better,
RUN CLOUD VFOXPRO whitout without RDP

http://foxincloud.com/

https://www.lianja.com/

https://www.west-wind.com/

Get more with the least changes?....

 

[Nigel Gomm]

Olaf,

how are you using the term "legacy" here?

actively being developed in VFP but win32 desktop so by definition legacy?

or do you mean written in fpw26 or older?

(my project with 1.3 million lines of code is the former - sorry if i wasn't clear; i didn't count them btw but ran it through the foxincloud analyzer a few years ago)

foxincloud,
i just sent a webmail thing on your website.... i may give you another look.

n

 

[Olaf Doschke]

Well, I'm talking about screens (not the _SCREEN). I make the distinction between Foxpro versions, where SCXes are based on the FoxPro form class vs where SCXes are processed to PRGs by GenScreen (similar to GenMenu).

I can't tell exactly where that transition is, but it's clear from the context, isn't it? I think the step from calling FoxPro Visual Foxpro was where SCXes structure changed and Microsoft introduced the Winforms based forms.

It's not important whether that application is current and was developed for decades and kept up to date in terms of the business case it's for. If it never was converted to Winform with control objects, you have a big difference. I don't see how the old way of screens is convertible at all to HTML forms. It's safe to say VFP4-9 projects are all using the forms FoxInCloud could transform, though I think it works best for VFP9 projects. You might need to upgrade to the recent VFP9, if you didn't do so far and when you started in something like VFP6 there only are mild changes necessary to get going in VFP9.

On the other side really old projects that still load in VFP9 because of its downward compatibility are working in VFP9 and in the end the windows are still WinForms, too, but all this is not class based, is it? As far as I know FoxInCloud analyses SCXes and VCXes to create the corresponding HTML forms the user finally sees, quite similar to what VFP2IIS does. And then Javascript events call back to a webserver which runs the real VFP desktop app in the background and binds this. You get something similar to TS, but the frontend is not just forwarding the desktop to clients, it renders as client side HTML(JAvascript. Not sure about all the details, but that makes it scale better than TS. It still has the same idea to run the application on the server "for reference". So it's unavoidable you also will have a good dimensioned servers, but I it's called FoxInCloud, so this surely is based on cloud hosting, which means scalable server side (cloud) resources, you don't provide the data center servers infrastructure or licenses and CALs, that's surely part of FoxInCloud Hosting and they could tell you details about that or other options.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Nigel Gomm]

Olaf,

ah ... VFP forms as opposed to @say.

I'd assumed OP (and foxincloud for that matter) was talking about VFP forms but of course you're right it's an important distinction.

n

 

[foxincloud]

FoxInCloud analyses SCXes and VCXes to create the corresponding HTML forms the user finally sees, quite similar to what VFP2IIS does

AFAIK, West Wind Web Connect's [tt]wwDHTMLform[/tt] was the first attempt to render a VFP form in HTML, so did VFP2IIS and FoxInCloud.

FoxInCloud pushes this logic farther than its colleagues:
[ul]
[li]clones forms as HTML/CSS/JS that not only replicates the VFP display, but understands the form structure to build responsive HTML[/li]
[li]supports everything that VFP can do (even what JavaScript frameworks don't officially support), including: any number of stacked modal dialogs returning value (of any type), all VFP base class except formset and toolbar (not very suited to the Web), mnx menus, public variables, _screen and _VFP properties, some activeX controls, etc.[/li]
[li]maintains the user's state on server side; many-to-many relation between servers and users[/li]
[li]processes all events using AJAX to deliver a user experience as comfortable as a desktop application[/li]
[/ul]

you don't provide the data center servers infrastructure or licenses and CALs, that's surely part of FoxInCloud Hosting

NO, NO and NO, we've written it over and over, and even on FoxInCloud home page:
"Give your Visual FoxPro applications a second life, web-based, in YOUR cloud"

It means that a company can deploy a FoxInCloud Web application on any server of its choice: LAN or WAN, internal or hosted, metal or virtual.
The only requirement is (because of VFP EULA) a Windows Server: any version including the latest (2019), 32-bits or 64-bits

I doubt FoxInCloud can convert them.

FoxInCloud does NOT convert anything, it requires the VFP app code to be adapted for deployement on the desktop as usual or on a Web Server.
No branching, no conversion, just the same VFP code base adapted for both uses.

I think it works best for VFP9 projects

FoxInCloud only supports VFP9 and VFPA.

 

[foxincloud]

VFP forms as opposed to @say

As Far as I remember:
[ul]
[li][tt].scx[/tt] are OOP forms for VFP 3+,[/li]
[li][tt]@say[/tt] screens were [tt].scr[/tt][/li]
[/ul]

 

[TamarGranor]

@FoxInCloud, that's not quite right. In FP2.x, you designed screens with the Screen Builder and the design was stored in an SCX/SCT pair. Then, you generated the code for that screen using GENSCRN, which resulted in an SPR (which was just a PRG by another name).

Tamar

 

[Olaf Doschke]

Indeed, the file pair names are equal, that means SCX/SCT file pairs do not necessarily identify VFP forms. And thanks for pointing out the processing was done with GENSCRN and resulted in SPR, Tamar, I got that wrong.

But this ambiguity of the file extensions for both screens and visual forms makes it impossible to conclude what avsalf deals with.

Bye, Olaf.


Olaf Doschke Software Engineering

https://www.doschke.name

 

[avsalf]

Sorry, I made a typing error exactly 1,727 SCX / SCT pairs 6,155,358 bytes.
They are built based on a class tree contained in a single VCX

 

[Olaf Doschke]

Anyway, as avsalf now has clarified about his project, this is a candidate for FoxInCloud. Have a go for this.


@Foxincloud, thanks for clarification. I know you're not replacing a Foxpro EXE and convert it to a completely independent web application, as I said:

And then Javascript events call back to a webserver which runs the real VFP desktop app in the background and binds this. You get something similar to TS,

You do build a HTML replica of forms with JS binding back to the EXE running on servers, don't you? And do you do that at runtime of the VFP exe or do you process the projects forms and form classes (and all the dependencies on control classes, etc) to get there? The answer to that doesn't even matter on the aspect of type of solution this is, this absolutely still goes in the same direction as TS, just with the frontend in HTML. This has to be generated based on the form and control objects part of Visual FoxPro.

On top of clarifying that you support VFP9 and VFPA you should also clarify that, or it doesn't stop users with legacy projects coming here asking questions about whether it would work if they can run their legacy SPRs on VFP9. To put this all into a pragmatic question: You don't turn @GET logic to HTML form input type text boxes, right? So before being able to apply FoxInCloud on such projects the first step would be to turn the screens into forms. VFP gives you the choice of visual vs functional conversion about that, and I remember faintly being educated there is something third party doing that better, but all this would already be much work in a larger project before even being able to start using FoxInCloud. And as I know there is a very upgrade resistant part of a Foxpro community which, in part, also led to the fact VFP was discontinued, at the same time they would like to make a stunt of jumping up to VFP9 standards and then furthermore to the Cloud.

But at least that's not the case here.

Just seeing that small family of form classes within the VCX, it makes me wonder if you couldn't have balanced this to a more detailed family of classes instead of building almost 2000 SCX forms from based on them. But that's a whole new topic. It's fun to see someone else making use of the possibility to set other icons for classes, but that's just an off topic remark.

Overall, good luck with that. Just remember, as you still run the EXE you still just have a fast track to perhaps serve more clients than with more traditional TS solutions.

Bye, Olaf.




Olaf Doschke Software Engineering

https://www.doschke.name

 

[foxincloud]

And do you do that at runtime of the VFP exe or do you process the projects forms and form classes (and all the dependencies on control classes, etc) to get there?

FoxInCloud generates the HTML, CSS and JS at run time, for each form, upon first time needed
eg.

- for a 'Master' form [tt]

https://mycompany.com/someForm.xxx

[/tt]

define class xxxProcess as awProcess && FoxInCloud sub-class generated by FAA
…
procedure someForm
this.wFormStandardPage('someForm.scx') && generates the HTML/CSS/JS if needed
external form someForm
endproc
…

- for a Child form:

procedure someForm.someControl.someEventOrMethod
…
&& ADAPTATION: FAA automatically replaces DO FORM by this instruction
thisForm.wForm('someForm.scx') && generates the HTML/CSS/JS if needed
external form someForm
…
endproc
…

The same form can be used as Master or Child form (as illustrated here)

You don't turn @GET logic to HTML form input type text boxes, right?

This is absolutely right; FoxInCloud supports only OOP forms and controls; VFP2IIS probably has the same support.

FoxInCloud needs to scan the container/class structure (form and its member) to generate the HTML/CSS/JS accordingly.

this absolutely still goes in the same direction as TS

Difference also lies in the relation between (logical) servers and clients:
[ul]
[li]TS has a 1-1 relation: the same client must be served by the same server (I think VFP2IIS also)[/li]
[li]FoxInCloud has a many-many relation: a client can be served by any server and a server can serve any client, even across different physical servers (with a load balancer front end).[/li]
[/ul]

 

[avsalf]

Thanks Olaf, very clear explanations.
I am going to start the project with only one part of my project, in this case it is a POS application (point of sale).
I will resume this post once I start and I will tell you my result.