Malcolm


You've pretty much got the idea - essentially split your app into front end & back end. Front end is mainly presentation & user interaction with the back end doing everything else. It probably helps if you're used to "proper" c/s with as much logic in the database as possible since you're almost there in that case.

Roy Lambert

On 12/18/2015 12:49 PM, Malcolm wrote:
> You seem to be saying I can use EWB to replicate my existing VCL app,
> then run it in the local browser on the scoreboard controlling
> computer.  So far so good.

That's definitely an option - as long as you write a proper back end web
service that handles the UDP side you should be all good.

The other alternative(s) in this case  that i can think of is to keep
the VCL logic and just replace the UI parts. For example :

1. The VCL app that is the back-end web server - meaning you run app and
then tell customer to launch a browser and connect to it's URL - i.e.
http://127.0.0.1:<your vcp app web server port>/

2. Another option is to have the VCL app with single form and that form
just hosts a built-in web browser component.

Whether it's external browser or internal browser you'd have an EWB app
then that talks tio the vcl app web browser and the vcl app would host
udp server and any other logic (including any db or other options for
saving data etc).

Sounds kind of funny but makes for a nice self-contained solution with
full capability (your delphi has delphi power and can use your existing
logic ; the hosted EWB app is UI. The whole thing is a single exe that
they just run).

The default TWebBrowser is IE based so kind of crappy but there are
number of projects out there that allow your app to host a custom
chromimum instance for example.

Raul

Roy,

<< This must be one of those cases where English and American have drifted apart. I suspect that the English word that would replace "nicely" is "correctly". There is no way on this planet that an app scaled down so you need a microscope to read it can be referred to as nice. >>

By "scale 100% nicely", I mean that there aren't any edge cases, etc. to worry about.  No matter what the resolution/scale used by the end user or their display drivers, the UI will look great.

<< But *(*^*^$&^$ that - HAPPY CHRISTMAS - just so I can be first to say it! >>

Thanks - Merry Christmas !

Tim Young
Elevate Software
www.elevatesoft.com

Malcolm,

<< You seem to be saying I can use EWB to replicate my existing VCL app, then run it in the local browser on the scoreboard controlling computer.  So far so good. >>

You use EWB to replicate the *UI* of your existing VCL app.  The rest stays the same, and you would use http to communicate between the two.  It's basically what Linux/Unix has had forever with the X window system - a separation of the display from the actual machine.

<< Then I need to include a UDPServer in the app to pick up the data packets, populate the datasets and thus display the appropriate data on the active page in the browser. >>

If you need to do "push" to a browser, then that's a little bit more complicated and involves web sockets, which EWB doesn't support right now because it's an IE10 or higher feature.  But, it's not too difficult to write an external interface for it so, if you need it, I can add it:

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

<< Most display controlling software systems work by defining a screen area which is then 'scraped' and fed to the electronic display.  So I would just size and position the browser window over that area. >>

Yes, that would work just fine.

<< I have no idea how I would get a UDPServer running in EWB.  Maybe I would need to do that externally and share the datasets.  Hmm. >>

As I said above, having to run a UDP server complicates things a bit because web modules aren't typically stateful and don't stay loaded longer than the duration of a connection.  You would probably have to combine the UDP server with the web server in the same binary, and have the UDP server notify the web server when it wants to push content back to the browser side of things.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

At present I parse out the data I want from a UDP packet and post it to
a few EDB tables.
The dozen or so display overlays (forms) include some DBText, DBGrid
(and other) components so the data is automatically displayed pretty
much in real time.

But if I use my existing VCL to maintain the local database and have a
separate EWB app also connect to that database will it track updates in
the same way or would I need to run a timer or equivalent to respond to
updates.  I need to display updates promptly .. or the user gets
impatient, hits the button again and jumps ahead.  

I think I will need to do a bit of prototyping ... when I have some
time.

Malcolm,

<< But if I use my existing VCL to maintain the local database and have a separate EWB app also connect to that database will it track updates in the same way or would I need to run a timer or equivalent to respond to updates.  I need to display updates promptly .. or the user gets impatient, hits the button again and jumps ahead.  >>

As I said, "push" is a bit of an issue, so if you need to do that, it certainly does complicate the use of a browser front-end if the browser application isn't running "bundled" in with your application (embedded IE/Chrome).

Tim Young
Elevate Software
www.elevatesoft.com

I have decided to kick this one into the long grass.
My existing program ain't broke.