As part of my quest to solve the issues raised by my problems with webspeed / GUI .r portability (http://communities.progress.com/pcom/message/95678#95678) , I want to be able to compile two directories with different versions of progress. Is this possible in OEA ?
IOW, compile directory 1 with prowin32, and directory 2 with _progres.exe
Or, of course, Psc could just fix the damned bug
You would have to split the directories into two separate projects, one marked for TTY and the other for GUI. The AVM for the builder runs persistently in the background and the GUI/TTY selection based on whatever is setup for the project.
Thanks, Matthew.
However, could you please tell me why I have to do this ? I don't
for anything else that doesn't use "CREATE OBJECT" com automation.
Julian
On the other hand, what is your objection to two projects? If you have server logic and client logic, one expects them to be in different projects with different properties, including a DB connection in one and not in the other.
If you had followed the thread, you would see that it's not client /
server logic at all.
I have a library class to interface with amazon S3 - this class
uploads files to the s3 bucket. This class can be called from either a
webspeed session or a prowin32 session or an appserver session. No DB
connections required at all.
The same source code runs on all three platforms - but the .r is
specific to the UI platform for some reason. So, I now have to
maintain these libraries outside the original project, and compile
them separately, and maintain 2 sets of .r code for the same class. I
don't have to do this for any other class or .p that I write - but for
some reason "CREATE OBJECT foo" (foo is COM-HANDLE) makes the .r code
non-portable across UI platforms.
Julian
On 21 June 2010 17:20, Thomas Mercer-Hursh
This won't solve your problem completely, but there is one thing that may help a little.
OEA is able to include individual PROPATH entries for a project based whether the AVM for the project is running either a TTY session or a GUI session. On the project PROPATH properties page, each PROPATH entry has an "Environment" node. For your own PROPATH entries this defaults to "all", but you can change it to tty or gui. This will allow you to optionally include that particular PROPATH entry based on whether the AVM is running _progres or prowin32. This applies to run configurations as well.
So after you build two separate .r files (for now), put both .r files in their own directories, and then add two propath entries, one for each, and then set the environment filter appropriately.
I can't comment on the com-handle issue itself as I don't deal with the compiler at all.
FWIW
Using Roundtable TSMS (and the corresponding plug-in for OEA), it's possible to designate certain objects for server compile, which means that those objects will be compiled on the server platform rather than on the OEA client. For example, while OEA may be running on 32-bit Windows 7, the TSMS server could be on a 64-bit Linux box. In that case, the objects (files) designated for server compile will compile on the server platform, resulting in 64-bit r-code.