Re: VARPG -- WDSCI-L

Can you explain a bit more, please?

1-Memory becomes less and less of an issue every year, but parts, so faras I know, do not take up memory until they are used.2-Not sure what this means. I suspect though that it may mean that youare trying to apply green screen design to GUI solutions, and arecramming a lot of stuff onto one window?3-Painting issues? I believe you, but of all the problems I ever facedwith VARPG, painting was negligible.

(Just as a additional comment, if anyone wants to see some screen shotsof VARPG windows, written in the same *RPG* that you already know,here's a link to some shots I posted a few years ago.)


http://tinyurl.com/dx7bc

As you look at them, realize that they are written in *RPG*. For somereason no one really believes that until they see their own firstapplication.

Here's a snippet of code; now tell me that you don't already know VARPG.:) One piece of information: BegAct means Begin Action. Everythingis event driven, there is no loop. So, until the user does something,nothing happens. But when the user does do something, just that eventis acted upon.

      *
      * Declare display size System attributes
     D%DSPHEIGHT       S              4  0
     D%DSPWIDTH        S              4  0

      * Declare %NewHeight, and %NewWidth event attributes. These will
      * contain the width and height of the window after it is has been
      * resized.
     D%NEWHEIGHT       S              4  0
     D%NEWWIDTH        S              4  0
      * The new mode of a window: ( 2 = minimized)
     D%NewMode         S              1  0

      *-------------------------------------------------------------------=
      *   Sample to resize a window                    Sub Routine =
*-------------------------------------------------------------------=
     C   ResizeSr BEGSR
      * Do not do if the new mode is "Minimized":
     C            If        %NewMode = 2
     C            Else
      * Set Container:
     C            Eval      %SetAtr('Main':'Container':'Width') =
     C                             (%NewWidth * .5) - 12
     C            Eval      %SetAtr('Main':'Container':'Left') = 4

C Eval %SetAtr('Main':'Container':'Height')

     C                      (%NewHeight * .5) - 10
     C            Eval      %SetAtr('Main':'Container':'Top') = 4
      * Set Calendar:
     C            Eval      %SetAtr('Main':'Calendar':'Width') =
     C                      (%NewWidth * .5) - 12
     C            Eval      %SetAtr('Main':'Calendar':'Left') =
     C                      (%NewWidth * .5)
     C            Eval      %SetAtr('Main':'Calendar':'Height') =
     C                      (%NewHeight * .5) - 10
     C            Eval      %SetAtr('Main':'Calendar':'Top') = 4

     C            EndIf
     C            ENDSR
      *-------------------------------------------------------------------=

* Set on last record:*-------------------------------------------------------------------=

     C     MAIN   BEGACT    DESTROY       MAIN
     C            Eval      *InLR = *On
     C            ENDACT
      *-------------------------------------------------------------------=
      *    Resizing a Window                                        =
*-------------------------------------------------------------------=
     C     MAIN   BEGACT    RESIZE        MAIN
     C            Exsr      ResizeSr
     C            ENDACT



Justin Taylor wrote:

My object-oriented comment referred to the fact that in VA-RPG, all
screen fields (parts in VA-RPG speak) must exist at compile time.

Which means:
1. All parts take up memory (more of an issue with PC apps)
2. Parts cannot be laid out via code, so overlapping parts are a pain
(not a problem with DDS)
3. Showing and hiding parts results in some strange painting issues (not
an issue with 5250)