• Got bored... wrote this... (2/2)

    From Bob Bobskin@21:1/5 to Gil Barmwater on Wed Apr 29 11:15:30 2020
    [continued from previous message]

    task2~key=.key~new("P")
    task2~key~alt=.true

    /*
    make some buttons which have tasks assigned to them.
    */

    okButton= .button~new("OK",10,20,25)
    okButton~task=.goToWindowTask~new(win,1)


    okButton2= .button~new("OK",10,20,25)
    okButton2~task= .goToWindowTask~new(secondwin,0)

    print2= .button~new("Print to File",10,50,25)
    print2~task=.printAllFieldsToFile~new(secondwin)

    clearTask= .clearEntryTask~new(win)
    clearButton= .button~new("CLEAR",10,50,25)
    clearButton~task= cleartask


    /* add all the widgets to the windows */

    /* the first window */

    win~add(label1)
    win~add(label2)
    win~add(input1)
    win~add(input2)
    win~add(input3)
    win~add(input4)
    win~add(okButton)
    win~add(clearButton)
    win~add(fieldhelplabel)


    /* and the second window */

    secondwin~add(label1)
    secondwin~add(label2)
    secondwin~add(input1s2)
    secondwin~add(input2s2)
    secondwin~add(okButton2)
    secondwin~add(print2)


    /* including something illegal here */
    wm~add("qaer") /* The system is effectively going to ignore this, treating it as a string against the WM */

    /*
    This is the population of the data management table with
    the field objects, along with the lookup name

    For a framework, the creation of a WMDMS service
    seems somewhat counterintuitive, until you think of the common use cases.
    This allows a single location, where one can define criteria as to which fields must be completed,
    which are are optional etc, and have the WM system understand the status of these.
    Then by virtue of setting up rules, validation is easier. It also to act as a simple method to fetch
    the current data values of the fields, by name, to avoid having to programatically trawl through each window to identify
    where a given field is. In my experience, due to design changes, fields often move around screens, so having them all centrally
    stored saves substantial time when refactoring, as it means that you don't have to change lots of code when you make minor layout changes
    */

    wmdms~put(input1,"input1")
    wmdms~put(input2,"input2")
    wmdms~put(input3,"input3")
    wmdms~put(input4,"input4")
    wmdms~put(input1S2,"input1S2")
    wmdms~put(input2S2,"input2S2")

    /*
    create a virtual screen and add it to the wm
    The purpose of a virtual screen is to allow you to lay out items based upon a 80x25 screen layout,
    and have it adapt if the screen layout is running in a window, and therefore can change.
    It should be noted that it does not change the size of widgets (as in, the length of them). They are still "FIXED" size,
    but it adapts where they are placed on the screen in an attempt to ensure that they are reasonably sensibly placed.

    The code currently makes some attempts to try to deal with resizing of the display (window) during runtime, but the code
    does not check for this event all the time, and as such, it can take a little while to adapt.
    */
    vscreen = .VirtualScreen~new()
    wm~add(vscreen)

    /*add windows to window manager along with two key activated tasks*/
    wm~add(win)
    wm~add(secondwin)

    /*
    add the keyboard bound tasks to the window as well, in this case to go to screen 1 and screen 2
    */

    wm~add(task1)
    wm~add(task2)

    /*
    add the data management serviec to the window manager
    */
    wm~add(wmdms)

    /* run window manager */

    wm~run()

    /* once wm has stopped the following will run */

    wm~logger~log( "Window Manager is shutdown",1)

    do i = 1 to 3
    say "shutdown "
    call syssleep(1)
    end

    /*
    ensure that this thread dies by killing all rexx running, rather brutal but this is a test application isn't it.
    */
    "killall -9 rexx"

    /* we are done */
    exit




    ::requires "tui.cls"



    On Wednesday, 29 April 2020 14:27:50 UTC+1, Gil Barmwater wrote:
    For anyone else who might be interested in using this on Windows, you
    should be aware that Windows 10 since 2016 supports ANSI sequences to
    the console. If you try it from ooRexx, however, it would appear to not work. This is the bug I referenced below. But after ooRexx invokes CMD
    the first time, the support becomes enabled so then ooRexx can use the sequences.

    On 4/29/2020 9:13 AM, Gil Barmwater wrote:
    Rony,

    I think the OP is Bob, not Chris. As for the issues you noted on
    Windows, you should be aware of an open bug against the ANSI escape sequence support. There is an easy workaround however; just issue a "dummy" command to cmd.exe - like 'rem' - before you (or Bob's code) issues any ANSI sequences. This will get the support enabled which it automatically is for cmd.exe but not (yet) for ooRexx. HTH,

    Gil B.

    --
    Gil Barmwater

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)