Cross-platform .r using com automation

Posted by jmls on 29-May-2010 01:27

How is this achievable ?

I have the following program:

USING Progress.Lang.*.
USING debtnet.library.*.
ROUTINE-LEVEL ON ERROR UNDO, THROW.
CLASS Component.ipworks.http : 
  DEF PRIVATE VAR http1 AS COM-HANDLE NO-UNDO.
  CONSTRUCTOR PUBLIC http():
    CREATE "IPWorks.HTTP" http1.
  END CONSTRUCTOR.
  DESTRUCTOR http():
    RELEASE OBJECT Http1.
  END DESTRUCTOR. 
/* ==========================================================================
   Post
   ==========================================================================*/ 
  METHOD PUBLIC VOID Post(p_http AS CLASS ValueObject.http):
    http1:post(SUBSTITUTE("http://&1:&2/&3&4&5",p_http:Server,p_http:Port,p_http:URL,IF p_http:PostData EQ "" THEN "" ELSE "?",p_http:PostData)) NO-ERROR.
    RETURN.
  END METHOD.
END CLASS.

There are *no* UI elements in here. This automation control is used on ASP pages.

I can compile it on each platform (win32 and _progres) and it works just fine. However, I cannot compile it using prowin32 and run it as a webspeed program, because I get the following error

Compiled UI of 'Component.ipworks.http' does not match runtime UI

WTF ? Where is the UI element in this code ?

Frustrated

This class is used by both webspeed and prowin32 agents - how do you manage this scenario for deployment ?

TIA

Julian

OpenEdge Development - Forum

All Replies

Posted by jmls on 11-Jun-2010 08:55

I have narrowed down the code that highlights this issue. I know that other people do not seem to have an issue, so I am trying to figure out what the differences are.

10.2B SP01

/* c:\temp\test.p
   This is the offending program */
DEF VAR foo AS COM-HANDLE.
CREATE "" foo NO-ERROR.
 

prowin32 -d dmy
compile c:\temp\test.p save.
run c:\temp\test.p

No errors.

pro -d dmy
run c:\temp\test.p
"Program c:\temp\test.p was compiled under another incompatible display environment.
Cannot run without recompile. (4438)"

Crap. so, let's recompile

compile c:\temp\test.p save.
run c:\temp\test.p

No errors

now let's try in the GUI

prowin32 -d dmy
run c:\temp\test.p
"Program c:\temp\test.p was compiled under another incompatible display environment.
Cannot run without recompile. (4438)"

can anyone reproduce this using the above steps ?

TIA

Posted by Stefan Drissen on 12-Jun-2010 17:48

Yes, I can reproduce the above. Using 10.2A02 32 bit on Windows Vista x64.

We do not use COM-HANDLEs at all so have not had any trouble with this.

So either:

1. put two versions in the same pl and RUN VALUE ( SESSION:DISPLAY-TYPE + ".foo.p":u )

2. have a gui and a tty pl and put the correct one in your propath depending on if you're running a gui or tty session

3. log a bug and wait for the release in which it is hopefully solved

Posted by jmls on 12-Jun-2010 23:19

Great - at least it's not just me going mad

Thanks

Julian

Posted by jmls on 21-Jun-2010 02:56

It would be great if someone from Progress can chime in here and let me know if I should raise a bug or not. This is *very* frustrating.

The problem with having two separate directories means that I have to either

A) have two sets of source code

b) try perform some trickery with external projects within OEA.

However, I still have the problem that I have to recompile after every project build the "char" UI and the "gui" UI.

Is there anyway of telling OEA to compile separate directories with either prowin32 or progres.exe ?

Posted by Laura Stern on 21-Jun-2010 13:02

This IS a bug.  So please log it.  Thanks.

Laura

Posted by jmls on 21-Jun-2010 13:13

yay! Boo!

Thanks ...

Julian

Posted by jmls on 21-Jun-2010 14:32

logged as W006210153

Posted by jmls on 02-Jul-2010 05:16

For those interested in this thread, I have been told by Tech support that this bug is fixed in 10.2B02

Julian

Posted by Stefan Drissen on 23-Feb-2011 14:40

Just ran into family of this issue. Compile the following in GUI and then run in in TTY or vice versa:

DEFINE VARIABLE hcp AS HANDLE NO-UNDO.
CREATE CLIENT-PRINCIPAL hcp.

Error: Program c:\temp\cp\cp.r was compiled under another incompatible display environment. Cannot run without recompile. (4438)

grrrr

Posted by jmls on 23-Feb-2011 14:59

oh, crap. That's not good.

I just started using client-principal like last month !

What version of progress are you running on ?

Julian

On 23 February 2011 20:40, Stefan Drissen

Posted by Stefan Drissen on 23-Feb-2011 15:04

.

out of office reply

Posted by Stefan Drissen on 23-Feb-2011 15:06

Occurs with 10.1C04 and 10.2B02 - I also just started using the client-principal about a month ago...

We have one super .p which is responsible for creating and reading the object so I've simply included the .p in a .p that is compiled with prowin32. When adding the super to the super stack the 'correct' super is run based on session:display-type.

Posted by jmls on 23-Feb-2011 15:14

Mmm. What about 10.2B03 ?

Julian

On 23 February 2011 21:06, Stefan Drissen

Posted by Stefan Drissen on 23-Feb-2011 15:39

I have not got a 10.2B03 environment handy at the moment - will get back on that next week.

Update: this has been confirmed and logged as bug OE00205151 by PTS.

Posted by jmls on 26-May-2011 13:15

ARRGGHHHHH.

Just been bitten by this. *Again*.

Grr.

CLIENT-PRINCIPAL is causing the problem in 10.2B04

Anyone got an idea of a fix ? Is there a hotfix for this ?

Posted by jmls on 26-May-2011 13:36

OH, Oh ohhhh noooooo

just thought I'd worked out a really smart workaround ...

CREATE VALUE("CLIENT-PRINCIPAL") ClientPrincipal.

ClientPrincipal:SESSION-ID = ...

believe it or not, this compiles and works ..

*however*

CREATE dynamic widget is not supported in webspeed

Foiled !

This thread is closed