Re: XPL early programming decision - whether to RC loop or custom .kbd

["Young For Life Products, Ltd" contact@xxxxxxxx]

Thanks, Jay, I'll have to look at the help screens you're talking about,
although I doubt they will do what I want. I usually find that things like
that that are intended to be shortcuts end up compromising what I really
want to do, and so I waste time on the shortcut because I end up writing
whatever I want from scratch anyway. But I could be wrong this time.

Charles

----- Original Message -----
From: Jay McNally 
To: 
Sent: Wednesday, November 07, 2001 5:57 PM
Subject: Re: XPL early programming decision - whether to RC loop or custom
.kbd


>
> The program you are describing is over my head. I have not done much in
the way of xpl in probably 6-7 yrs and have forgotten a lot of it.
>
> I think the old help screens are the kind of thing you might be
describing, or which would help. With those screens, you enter a new level
of tier within the program that does not accept any keystrokes except those
which are being prompted for... as in a numerical menu, 1-10, or a list.
>
> That kind of thing is easy to write ... you create an array and tell the
computer to go to another loop if a key outside the array is pressed.
>
> There are, as I recall it, as many as 7 or 9 separate kinds of help
screens. Some are very, very clever. And each is tailored for a specific
kind of presentation of data.
> And naturally, you can adapt them to any kind of project in Xy.
>
> I tinkered with them back in about '91 or 92 and found them full of
opportunity, but never took it beyond minor tinkering.
>
> I have never used U2, so it is possible that that program has replaced all
the other Xy stuff.
>
> I think the experts are Carl D. and R. Holmgren. They coudl probably
recognize what you planning and have pretty good options for it.
>
> One thing that amazes me here -- I've been on this list for only about 2
months -- is that just about every problem I've encountered, the others on
the list have solved.
>
>
> >
> > From: "Young For Life Products, Ltd" 
> > Date: 2001/11/07 Wed PM 04:41:30 EST
> > To: 
> > Subject: Re: XPL early programming decision - whether to RC loop or
custom .kbd
> >
> > I am starting to write this XPL overview program, for organizing ideas
and
> > pieces in a writing project, and I have a key decision to make:
> >
> > for a screen which the user will use frequently, entering and exiting it
> > automatically as they dip in and out of various parts of the whole
project,
> > I need to control the keyboard. Probably about twenty different actions,
> > including cursor control to specific places on the screen, and menu
actions.
> > In addition there will be allowed input of alphanumeric characters for
> > placing names in various parts of the screen.
> >
> > I can either write a series of RC loops that leaves the default keyboard
> > alone, just temporarily captures input while the user is at that screen,
or
> > I can temporarily load a special keyboard for during the time the user
is at
> > that screen, and when that screen is exited, the user's default keyboard
is
> > reloaded.
> >
> > When the user is actually writing in a part of the project, not
overviewing
> > the whole project, they are in a file and are not actually in the
overview
> > program any more. All xywrite functions are available. When they go to
save
> > the file, they invoke the program again through a hotkey or command line
> > command, and the program stores the file properly within the framework
of
> > the overview program.
> >
> > I incline toward the RC loop while at the overview screen, but am
curious
> > how expert programmers would handle this. If I went with the .kbd idea,
I
> > have to figure out how to capture the info of what .kbd file is
presently in
> > use (I assume there's a function call for that) before invoking the
overview
> > screen and temporary overview keyboard. I guess I could just assume it
would
> > be called xy4.kbd, write it just for xy4 and let xy3'ers rewrite that
part
> > of the program, but that still seems risky, considering the
sophistication
> > of many of the people likely to use this program.
> >
> > Charles
> >
> >