Re: VARPG

[Booth Martin <booth@xxxxxxxxxxxx>]

Can you explain a bit more, please?

1-Memory becomes less and less of an issue every year, but parts, so far 
as 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 you 
are trying to apply green screen design to GUI solutions, and are 
cramming a lot of stuff onto one window?
3-Painting issues?  I believe you, but of all the problems I ever faced 
with VARPG, painting was negligible.

(Just as a additional comment, if anyone wants to see some screen shots 
of 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 some 
reason no one really believes that until they see their own first 
application.

Here's a snippet of code; now tell me that you don't already know VARPG. 
  :) One piece of information: BegAct means Begin Action.  Everything 
is event driven, there is no loop.  So, until the user does something, 
nothing happens.  But when the user does do something, just that event 
is 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)