I came across this problem when compiling objects under Roundtable when it was configured to run under Appserver. All my compiled GUI objects when executed wiithin my application return Progress error:
Program <program-name> was compiled under another incompatible display environment. Cannot run without recompile. (4438)
I first thought that there is something wrong with Roundtable but support guys pointed (probably rightly) that this is the nature of Appserver which is basically a TTY client.
I feel that this is not quite the way it should behave. The assumption that we have to compile all objects with TTY metrics does not make sense, or does it?
Yes, you need to compile programs for the right "display environment". That means your GUI programs need to be compiled for a GUI client and TTY (including AppServer) programs, for TTY. This behaviour in itself has nothing to do with RoundTable.
What you'll probably need to do is find out whether you can set the display environment for individual programs or modules in your version of RoundTable.
Where it starts to get interesting is when you have the same program (eg. validateCustomerDetails.p) which might be called from both display environments. That said, last time I was actively involved in a RoundTable project, we were shipping the (xcoded) .p's in the deployment and running the update program at the target sites (_update.w??). This compilation process was then always correct for the environment we were on.
That said, I may be missing something here, so you probably should check with the guys from Tug Boat.
What you'll probably need to do is find out whether
you can set the display environment for individual
programs or modules in your version of RoundTable.
>
Well, I have and no you cannot.
Where it starts to get interesting is when you have
the same program (eg. validateCustomerDetails.p)
which might be called from both display environments.
My validation routines do not "display" anything on UI as they may belong to BL layer. Rather, they return values to UI layer which then handles them according to UI presentation logic. So this is not problem that I am talking about.
That said, last time I was actively involved in a
RoundTable project, we were shipping the (xcoded)
.p's in the deployment and running the update
program at the target sites (_update.w??). This
compilation process was then always correct for the
environment we were on.
Deployment is not a problem. I am talking here about "compile" functionality available from Roundtable tabletop.
So, you have not answered my question but thanks for trying.
I think, the problem is Progress itself, which incorrectly assumes that all objects should be compiled with TTY metrics if the session is running in distributed environment.
You may want to check the PEG "roundtable" forum and see if they have any information about this.
http://www.peg.com/lists/roundtable/web/
This is only a problem if you are using UI stuff in your BL. If your BL is really only BL and has no UI then it can be compiled using TTY or GUI and can be run by either.
The following 'BL':
DEF VAR c AS CHAR INIT "hurrah".
MESSAGE c.
Can be compiled as TTY and then run on either TTY / GUI client. It can also be compiled as GUI and run on either TTY / GUI client.
As soon as you include (for example) a DEFINE FRAME statement this interoperatiblity stops.
So: ensure that your business logic contains no UI stuff - compile all business logic with TTY client and the rest with GUI client.
You are missing my point completely.
This is not about BL and UI layers, this is about compiling objects regardless to what layer they belong under distributed (with AppServer) Roundtable.
Plese read my original post carefully.
BTW, Roundtable blokes that I've talked to, confirm that this is Progress' problem. And I tend to agree.
OK,
1. I have no knowledge of Roundtable (aside knowing what it does).
2. The problem is that an AppServer (distributed) is being used to compile all objects?
3. Which is therefore resulting in all sources with GUI stuff returning the error?
Resulting in a distributed compile being a no go...
The executable normally fired by an AppServer is _proapsv.exe which is a tty based AppServer. Just wondering if it would be possible to probuild an AppServer based on prowin32.exe?
Hmmm.... just had a quick browse of what probuild does on a Windows platform - it is simply creating a different prow32.dll - and is not resulting in a different executable as it does on *NIX... So it looks like a dead end.