Client connected by Application Windows or AppServer - Forum - OpenEdge General - Progress Community

Client connected by Application Windows or AppServer

 Forum

Client connected by Application Windows or AppServer

  • Someone can indicate me as I will be able to know the client was connected by road Appserver or road Application Windows?

    Already I experienced this code but done not function.

    Programa.p ( Progress version 10.1B)

    &IF SESSION:DISPLAY-TYPE NE "TTY":U &THEN

    Message “client connect running Application Windows” view-as alert-box.

    &ELSE

    Output to “c:\appserver.log”.

    Put “client connect running Appserver” skip.

    Output close.

    &endif

    Thank!

  • SESSION:REMOTE is usually a good check to know if the current code is executed on the client or the appserver.

    If you're appserver "portion" of the application can run on the client depending on the deployment configuration, you can check

    IF hAppServerHandle = SESSION:HANDLE

    on the client to know that the appserver portion of the app is running locally on the client.

  • But Session:remote cannot be evaluated in preprocessor expression.

    I need to identify in an expression of preprocessor...

    something similar to:

    &IF SESSION:REMOTE &THEN

    Message 'client connect running Application Windows' view-as alert-box.

    &ELSE

    Output to 'c:\appserver.log'.

    Put 'client connect running Appserver' skip.

    Output close.

    &endif

  • The issue is SESSION:REMOTE is valid during runtime only, and the &IF directive is used at compile time to determine if a block of code should be compiled into the .r.

    Why not just use a standard IF construct?

  • for the following

    If ClientAppserver then

    Else /ClientApplicationWindows/

  • The question here is that it is the execution which is on the AppServer or local, not the compilation, so there is nothing to test at compile time. Just use standard preprocesser tests to include different code or include a single block of code which does the runtime test to select which code to execute. Hating preprocesser code, my recommendation would be the latter unless there were really large amounts of code involved. Were that the case, I would decompose into a small piece of code which made the choice and two separate pieces of code, one for each option.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • or create 2 classes, one for local, one for remote implementing an interface

    IF SESSION:REMOTE THEN ClientMode = NEW RemoteClient().

    ELSE ClientMode = NEW LocalClient().

    ....

    ClientMode:ShowMessage("MyMessage")

    ....

    &IF SESSION:REMOTE &THEN

    Message 'client connect running Application

    Windows' view-as alert-box.

    ELSE

    Output to 'c:\appserver.log'.

    Put 'client connect running Appserver' skip.

    Output close.

    dif

  • Which is pretty much what I said, only without confusing them necessarily about using OO.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • who says that OO is confOOsing ?

  • But Session:remote cannot be evaluated in

    preprocessor expression.

    That's totally true! If a procedure or class does not produce any form based output there is no difference in the R-Code that makes it appserver runnable or not. So I really see no way how the compiler (or the preprocessor) shall know if a code section will be used by calling routines (separate compile units) on a client with/without DB or on an AppServer.

    The only chance you have is to provide two routines (.p or .cls) with the same/similar procedure. One for the client serving as a proxy, one for the server, doing the work. A fat client does not need the proxy - it can work with the server procedure or object.

    Check src/dynamic/ry/prc/ryrepclnt.p and src/dynamic/ry/app/ryrepsrvrp.p

    They share a common include file for the majority of the code (99% +) and use

    &global-define server-side YES

    or

    &global-define client-side yes

    to control which code needs to be running on a server or a client. But it's the calling code, that is responsible to execute the right one on the client or the server.

    These sample files are part of Progress Dynamics. Source code is part of any OE Dev license (when you choose to include Dynamics).