Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Your crystal ball?
Message
 
To
20/10/2020 14:48:26
John Ryan
Captain-Cooker Appreciation Society
Taumata Whakatangi ..., New Zealand
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01676408
Message ID:
01676760
Views:
84
Likes (1)
>I was thinking along the lines of that SCX to dHTML renderer

Basically that's FoxInCloud is doing today...

The problem with a renderer is that it falls apart very quickly unless there's a lot of external stuff that's specific to the HTML platform. This is why I long ago discontinued work on the original dHtml renderer - it would have been an endless support nightmare trying to make all the crazy combinations of controls and FoxPro behaviors work - especially with people then expecting them to work the same as FoxPro did.

This is where FoxInCloud picked up where I left off and they are doing basically the hard work of providing the infrastructure to actually produce the HTML and support behavior that has to be available ontop of just the rendered form output. And if you go to their message board you can see what I mean - there are lots and lots of edge cases that need to be addressed - and Thierry and team do a great job of addressing those, but I imagine it's a monumental job. Comapred to Web Connection FIC is likely exponentially bigger in terms of scope.

There are a lot of external dependencies to make even standard FoxPro controls work - simple rendering of a form is not enough. FoxInCloud actually provides that with a complete framework that provides the behavior for stock controls plus a host of common activeX controls. You can't do that with **just** HTML rendering and so I don't think having a native HTML renderer is going to really be very useful in the language on its own unless a big effort goes into building a client side support framework (ie. rebuild something similar to FoxInCloud).

>BTW, thanks for highlighting this string stuff; I'd used textmerge for years (as did Web Connect once upon a time!) and was very pleased to see that string concatenation was subsequently made more efficient as you've published more than once. AFAICS you are the main reason that gem was exposed in the wider community. So, thanks!

Yeah those were the good old days when there still was a Fox team and they actually wanted to improve things. I spent a few debugging sessions with Calvin back in the day (to fix COM issues) so I have an idea of the complexity of the FoxPro source code. It's not a nice or maintainable code base to work on, with a lot of crazy inside knowledge and special case logic embedded in it especially for optimizations like string concats, special COM casing for certain object types etc. This is one of the reasons I'm skeptical of how stable any major updates to that code base would be especially without all of the MS regression testing harnesses they had set up to ensure that nothing broke when changes were made.

+++ Rick ---



>>>What do you think you would get beyond a FoxPro solution? AFAIK I haven't heard of the script or even the template rendering being a bottle neck in big applications. The bottleneck invariably is always long running FoxPro code operations, not the string output generation thanks to the string optimizations Calvin made in VFP 8 and 9.
>
>I was thinking along the lines of that SCX to dHTML renderer you wrote once upon a time that's probably only remembered now by the likes of you and me. ;-) So not re-writing the underlying HTML5 rendering engine, just hooking into it on each platform. As you might expect I've done that using WW for years at the server, but I'm imagining a native app doing the same thing.
>
>BTW, thanks for highlighting this string stuff; I'd used textmerge for years (as did Web Connect once upon a time!) and was very pleased to see that string concatenation was subsequently made more efficient as you've published more than once. AFAICS you are the main reason that gem was exposed in the wider community. So, thanks!
>
>for the rest: my phone is more powerful than the 386x used to develop my first ever windows app. So now I imagine a native cross-platform 4GL that can produce cross-platform apps, just as Fox promised almost 30 years ago. The big challenge of matching cross platform UI has since been solved by others in the form of HTML5/Javascript etc that we know can be produced relatively easily, so even a cross-platform FP2.0 would be better than options I've reviewed to date. I'm not wed to Fox but if I can't find anything else, why not? Yeah I know there's some disagreement at the idea of native apps over web apps, but I'm fairly happy with my reasoning.
+++ Rick ---

West Wind Technologies
Maui, Hawaii

west-wind.com/
West Wind Message Board
Rick's Web Log
Markdown Monster
---
Making waves on the Web

Where do you want to surf today?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform