Skip to main content

[archive] Odd display reaction

  • April 5, 2007
  • 2 replies
  • 0 views
D

[Migrated content. Thread originally posted on 05 April 2007]

Using version 5.2.1.1

codefrag:

PERFORM X000-WINPRINT-INIT.
DISPLAY STANDARD WINDOW
LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

shows an inactive screen. You have to click on the screen to activate it.

Changing this to :

DISPLAY STANDARD WINDOW
LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
PERFORM X000-WINPRINT-INIT.
DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

Fixes the problem - the screen is active.

So - the problem must be in X000-WINPRINT-INIT.

X000-WINPRINT-INIT SECTION.
X000-WINPRINT-INIT-START.
INITIALIZE WINPRINT-SELECTION.
CALL "WIN$PRINTER" USING WINPRINT-GET-NO-PRINTERS,
WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
PERFORM X100-WINPRINT-CURRENT.
X000-WINPRINT-INIT-EXIT.
EXIT.

X100-WINPRINT-CURRENT SECTION.
X100-WINPRINT-CURRENT-START.
CALL 'WIN$PRINTER' USING WINPRINT-GET-CURRENT-INFO,
WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
X100-WINPRINT-CURRENT-EXIT.
EXIT.

Commenting out the "PERFORM X100-WINPRINT-CURRENT." fixes the problem with the original codefrag (but doesn't get the current info, obviously.)

GET-CURRENT-INFO-EX produces similar results.

Since I can live with performing the procedure after the DISPLAY STANDARD WINDOW I'm not particularly concerned - just curious why the change would cause the screen to change between being active and inactive.

Anyone got any clues about this?

    2 replies

    D

    [Migrated content. Thread originally posted on 05 April 2007]

    Using version 5.2.1.1

    codefrag:

    PERFORM X000-WINPRINT-INIT.
    DISPLAY STANDARD WINDOW
    LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
    DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

    shows an inactive screen. You have to click on the screen to activate it.

    Changing this to :

    DISPLAY STANDARD WINDOW
    LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
    PERFORM X000-WINPRINT-INIT.
    DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

    Fixes the problem - the screen is active.

    So - the problem must be in X000-WINPRINT-INIT.

    X000-WINPRINT-INIT SECTION.
    X000-WINPRINT-INIT-START.
    INITIALIZE WINPRINT-SELECTION.
    CALL "WIN$PRINTER" USING WINPRINT-GET-NO-PRINTERS,
    WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
    PERFORM X100-WINPRINT-CURRENT.
    X000-WINPRINT-INIT-EXIT.
    EXIT.

    X100-WINPRINT-CURRENT SECTION.
    X100-WINPRINT-CURRENT-START.
    CALL 'WIN$PRINTER' USING WINPRINT-GET-CURRENT-INFO,
    WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
    X100-WINPRINT-CURRENT-EXIT.
    EXIT.

    Commenting out the "PERFORM X100-WINPRINT-CURRENT." fixes the problem with the original codefrag (but doesn't get the current info, obviously.)

    GET-CURRENT-INFO-EX produces similar results.

    Since I can live with performing the procedure after the DISPLAY STANDARD WINDOW I'm not particularly concerned - just curious why the change would cause the screen to change between being active and inactive.

    Anyone got any clues about this?
    When WIN$PRINTER is getting information on the current printer, it is involving the printer setup dialog. Not visibly of course, but nevertheless. This call to the the windows api printer setup dialog also involves the handle to the window of the calling application, e.g. the cobol application. Thus, prior to the call, there is a check for the current window of the cobol application, and if there is no such the master window is created, albeit invisible. This creation/inquiry also makes the window current, thus your experience.
    You might find this annoying, but keep in mind then, that if we had not made the runtime behave like this, you would have a lot more coding to do, not only for the printer, but also a lot of other common tasks.
    D

    [Migrated content. Thread originally posted on 05 April 2007]

    Using version 5.2.1.1

    codefrag:

    PERFORM X000-WINPRINT-INIT.
    DISPLAY STANDARD WINDOW
    LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
    DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

    shows an inactive screen. You have to click on the screen to activate it.

    Changing this to :

    DISPLAY STANDARD WINDOW
    LINES HT-SCREEN SIZE WI-SCREEN BACKGROUND-LOW.
    PERFORM X000-WINPRINT-INIT.
    DISPLAY SCREEN-1. ACCEPT SCREEN-1 ON EXCEPTION CONTINUE.

    Fixes the problem - the screen is active.

    So - the problem must be in X000-WINPRINT-INIT.

    X000-WINPRINT-INIT SECTION.
    X000-WINPRINT-INIT-START.
    INITIALIZE WINPRINT-SELECTION.
    CALL "WIN$PRINTER" USING WINPRINT-GET-NO-PRINTERS,
    WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
    PERFORM X100-WINPRINT-CURRENT.
    X000-WINPRINT-INIT-EXIT.
    EXIT.

    X100-WINPRINT-CURRENT SECTION.
    X100-WINPRINT-CURRENT-START.
    CALL 'WIN$PRINTER' USING WINPRINT-GET-CURRENT-INFO,
    WINPRINT-SELECTION GIVING WINPRINT-NB-RESULT.
    X100-WINPRINT-CURRENT-EXIT.
    EXIT.

    Commenting out the "PERFORM X100-WINPRINT-CURRENT." fixes the problem with the original codefrag (but doesn't get the current info, obviously.)

    GET-CURRENT-INFO-EX produces similar results.

    Since I can live with performing the procedure after the DISPLAY STANDARD WINDOW I'm not particularly concerned - just curious why the change would cause the screen to change between being active and inactive.

    Anyone got any clues about this?
    So - Uncle Bill's system at the root of the problem. How unusual.

    Good explanation - thanks!

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement