CHUI development and OE Architect

There is a run as TTY option in OEA, which will be code running on Windows, but it can be running against the Linux database and show them what the application will look like. Then it is only a question of doing the compile on the Linux side to finish off. Myself, I do that with a tool in the application anyway.

Thomas,

Thanks for the advise. Is it possible to set up the project environment to default to tty when they compile/run their code ?

I'm a bit confused - OEA is a windows-only tool, but the linux code's running on a telnet session - correct?

If so, then all you can use OEA for is the editing / project / etc. side of things. The code itself would need to be run on the linux box.

I've done development work using windows for editing code, etc. with samba mapped drives to the unix machine source code directories. Putty gets me to the unix machine to run the code. Works great.

The TTY can run on Windows in client/server mode using the code from the Linux with the database on Linux. Other than that, yes, you could always keep a telnet session open and use an application-based compile tool.

I don't think you can set it up as a default because the default runs the code in the instance being used for the local syntax checking and such, but there is Run As TTY on the standard right click menu and a Run Configuration there as well, which allows further special configuration, and both start a new separate session to run the code. Among other things, this makes it direct to do things like run a menu program to start.

The TTY can run on Windows in client/server mode

using the code from the Linux with the database on

Linux. Other than that, yes, you could always keep a

telnet session open and use an application-based

compile tool.

Yes, you can do that.

I'm just wondering why one would want to...

Well, it is pretty much what I used to do pre-OEA. I used ED4W reading the files off a samba share mounted on the Windows box and then had telnet or ssh clients where I could compile and test the code. I still do that when I am working on a customers machine via VPN.

Well, it is pretty much what I used to do pre-OEA. I

used ED4W reading the files off a samba share mounted

on the Windows box and then had telnet or ssh clients

where I could compile and test the code. I still do

that when I am working on a customers machine via VPN.

We're missing each other here - I can see using ED4Win via samba share and telnetting to the machine to do the work.

I'm wondering why one would want to run the code on their local machine off samba shares to a remote machine, and connect to the db there as well.

If one had a local db, etc. I can see doing that, but running c/s to a remote machine vs working on the remote machine via telnet / etc. seems to be doing things the hard way.

Other than some minor setup, I don't see running TTY client/server as being much different than running with regular telnet sessions. The virtue of one over the other might depend partly on the context. E.g., if one has multiple developers, it is easy for each of them to test out local code which lives on their own machines with a PROPATH going back to the shared code on the Linux box and it is very easy to stay out of each others way. To run that code on the Linux box would take a development area per developer ... also not difficult.

Hi Guys,

Thanks for all your input. The customer runs their application via telnet but the development team wish to use all the new features that come with OEA for productivity reasons.

The only option I saw was SAMBA to satisfy the above objective for the development team as OEA does not run on Linux directly.

The reason that I asked about project environment settings was that OEA automatically compiles the code on save (which of course not valid for their target environment) so I initially discarded the idea of a Putty(or similar) approach.

On reflection, I can get OEA to compile to a seperate set of directories and make sure that the propath (for the Putty session) does not access those .r's. They can then use the compile on the fly functionality to see their changes in a Putty window.

Or use run as tty.

In either case, they will need to recompile for Linux (possibly when promoting changes to a test environment).

The discussion has been good food for thought.

You can turn off that compile on save, but I think your approach is the better one. No reason not to have local .rs and the functionality that comes with it.

Some more info from KB entry P123598

http://tinyurl.com/2jxbft