Re: [slang-users] Major Milestone and some QUESTIONS ......

[Ben Duncan <ben@xxxxxxxxxxxxxxxxxx>]

Ok, thanks. Then I will continue on with my version. It is
designed to keep up with "virtual windows" in a stack like fashion.

FOr example, current window (which may be the 6th in the list) declares
it's coordinates are (from Row 0 col 0) row 5, col 20 for 12 rows and
50 columns. All addressing is done "relative to zero", meaning if I
say display a line of data in row 1 column 2, the ACTUAL RADIX addressing
would be row 6 column 21 and the user is freed from knowing exact addressing
coordinates - Just that he wants in items displayed/entered in current window
and starting in the second row and the third column of current window.

The stack like functions mean each window must be completed or exited.
One cannot "focus" on a particular window. This is in line with MOST data
entry style Accounting Applications. The Caveat to all this is the
wonderful "Quick Select" tied to FK4. The idea is if you are in the
middle of entering BIG CO's order and your bud Jim calls up for a quick
price/stock check, FK4 would bring up the "Quick Select", you would
select the price/stock check program , it would run it, then exit and
you would be right where you left off in the order.

The question about SLWDG/NEwt is to figure out how the prompts ran thru
the system. The scenario with SLAG is coming up with a way to do this:

A: We are adding a new record so go thru each prompt item. After the last
   prompt item on the screen ask any changed? if the answer is YES, prompt
   for which Item number. And then go and do that prompt. Continue on
   afterwards to the NEXT positive numbered screen and prompts. Repeat.

B: We are editing and existing record. After calling it up, do a
   "C(hange D(elete F(ill" prompt where Change ask for which prompt number,
    Delete will delete that record, and Fill will go thru all the prompts
    with the data filled in (Like an add mode, but with data)

The trick is to invent some sort of method of navigating screen/prompts
stacks. BUT, I have source to some really old MCBA COBOL programs and the
COBOL applications did this themselves, and since it was very structured code
they were not really very big programs. SO I may just force the developers of
the SLAG S-Lang scripts to do likewise (Think FoxPro like Applications here).

Any ideas, suggestions, pro's cons?


John E. Davis wrote:
<SNIP>
> All the SLsmg_set_screen_start function does is set the origin for the
> upper-left corner of the physical display.  This has the effect of
> allowing the application to pan.  For example, suppose this function
> is used to give the upper-left corner the (logical) coordinate
> row=0,col=40 as follows:
>
>    int r0=0, c0=40;
>    SLsmg_set_screen_start (&r0,&c0);
>    SLsmg_gotorc (0,0);
>    SLsmg_write_string ("01234567891123456789212345678931234567894abcedf");
>
> This will cause the just the "abcdef" portion of the string to be
> displayed because only those characters in the string will be have
> logical column coordinates >= 40.  The effect is that the display has
> been panned to the right by 40 columns.

<SNIP>

>

> The main event loop in called SLwdg_take_input.  What it does is very
> simple.  It loops performing these actions:
>
>     update the display
>     read a keysym
>     sends the keysym to the current widget (focus_proc method)
>
> The display is updated by looping over each of the widgets redraw
> methods.  The main action occurs in the currently focused widget's
> focus_proc where widget specific things are performed.
--
Ben Duncan   - VersAccounting Software LLC 336 Elton Road  Jackson MS, 39212
"Never attribute to malice, that which can be adequately explained by stupidity"
       - Hanlon's Razor


_______________________________________________
To unsubscribe, visit http://jedsoft.org/slang/mailinglists.html