***SPAM*** RE: ***SPAM*** RE: popup update * show statements

[John Esak]

That's cool. I do the same sort of thing.  Tim's programs used the idea of
using a variable SN to set what happens in AUTO processing with the actual
screen.  So by changing SN either by hitting a screen number or just because
of some other processing, the SCREEN command or some other would change the
screen, this in turn can easily change all the prompts so they are
appropriate for each screen.

I've even done such strange stuff as this. Like your key which scrolls
through the prompts, I intercept the left and right arrow keys.[1] The
prompts move steadily right or left... Saying "<more>" on the right side of
the screen until you reach the end, then the <more> switches to the left
side of the screen. It kind of gave you a sense of which direction the
scrolling was going and that there were more prompts to go in that
direction. I copied the idea from the way the browse does this on the top
and bottom of a browse.  Eventually, I took the <more>'s away. They became
problematic for some reason... I think because they took up more space than
they were worth.

John

P.S. You mentioned the Scripsit prompts the other day. They were cool. Each
prompt tied to the available F-keys... And if you held down Ctrl or Shift
or Alt you saw a different set of keys.  Of course, this behavior could not
be duplicated in filePro. 

[1] This is only possible if you adopt the philosophy of taking complete
control of the keyboard @entsel.  This technique has been discussed here
several times, and displayed in various postings and an old Guru Magazine as
well. It basically entails intercepting *every* keystroke @entsel and
PUSHKEYING them back into the buffer.  If you want to do something if that
key is pressed you can, if you don't, it just gets sent down the keyboard
buffer as normal.  This is not dead easy...  Well, yes, it's easy, but it is
tedious. You have to do things like intercept the up and down arrow for
example and make sure they progress to the correct next or previous record,
and so forth.




> -----Original Message-----
> From: Richard Kreiss [mailto:rkreiss at gccconsulting.net] 
> Sent: Saturday, January 09, 2010 4:28 PM
> To: john at valar.com
> Subject: RE: ***SPAM*** RE: ***SPAM*** RE: popup update * 
> show statements
> 
> John,
> 
> I am using @key/ to change the display of the user prompts.  
> Since @key runs
> auto processing, the coding for the prompts is here.  Depending on the
> number of displays, I have a variable the increments each 
> time @key/ is
> executed.  When it hits the last number, it is reset.  As I 
> type this I
> could use @key\ to scroll backwards through the prompts.
> 
> Richard
> 
> > -----Original Message-----
> > From: John Esak [mailto:john at valar.com]
> > Sent: Saturday, January 09, 2010 11:18 AM
> > To: rkreiss at gccconsulting.net
> > Subject: ***SPAM*** RE: ***SPAM*** RE: popup update * show 
> statements
> > 
> > Yes, the -d makes using @key prompts so much easier.  I 
> have a subroutine
> in
> > all my programs called "legend" (like the legend on a map) 
> and I GOSUB it
> > every time it's needed... Like @entsel and other screen 
> switching.  If
> > anyone wants it I'll put it up. I think I have before. I 
> took a lot of
> care
> > to exactly duplicate the filePro factory-standard legend, 
> including the
> > Screen  #, and Record # prompts on line 21, etc. From this 
> basic look, I
> add
> > and subtract my @keys or akey that says More Choices, or 
> Menu or a host of
> > other things that all mean the user can get to more prompts.
> > 
> > Incidentally, when using the -d for those who have never 
> used it, it's
> > important to note that the prompts are the only thing that are not
> > "displayed".  The factory-standard @keys are still all 
> *active*.  You
> won't
> > see them, but H-Hardcopy, B-Browse, U-update and so on all 
> still work. So,
> > you have to deal with this on your INPUT processing table 
> if you want to
> > change that. And, of course, at all the points where you 
> don't see Press
> ESC
> > to Record, Press DEL to Cancel (or whatever the default 
> actually is) these
> > keys will still work there also. They are just not visible.
> > 
> > John
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Richard Kreiss [mailto:rkreiss at gccconsulting.net]
> > > Sent: Saturday, January 09, 2010 10:08 AM
> > > To: john at valar.com; 'filePro List'
> > > Subject: RE: ***SPAM*** RE: popup update * show statements
> > >
> > > John,
> > >
> > > This is not a problem.  I am already putting up custom
> > > prompts.  In some
> > > case I have rolling prompts similar to what Scripset has 
> years ago.
> > >
> > > I just need to check my working menu options as I have IUA
> > > *clerks with and
> > > without the -d option.
> > >
> > > -d actually make it easier for me to control visibly what is
> > > available to
> > > the user.  I use a lot of @key functions.
> > >
> > > Thanks for the reminder.
> > >
> > > Richard
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: John Esak [mailto:john at valar.com]
> > > > Sent: Friday, January 08, 2010 9:47 PM
> > > > To: rkreiss at gccconsulting.net; 'filePro List'
> > > > Subject: ***SPAM*** RE: popup update * show statements
> > > >
> > > > Richard,
> > > > Unfortunately, I think you have run into one of the
> > > difficulties with
> > > > original filePro design. You can get around it, but only
> > > with a hammer.  I
> > > > started using this hammer about 10 or 15 years ago and I've
> > > never looked
> > > > back or done it any other way ever since. You need the -d
> > > on your command
> > > > line. In other words by putting the -d on the calling 
> line filePro
> > > "doesn't
> > > > display" (is the best mnemonic I can think for it) all the
> > > default prompts
> > > > at the times it normally displays these.  I know you've
> > > probably used the
> > > -d
> > > > a lot, but the times you don't that old behavior creeps up
> > > and hits you
> > > when
> > > > you least expect it.  There is only one drawback to using
> > > -d, and that is
> > > > *you* must provide all the prompts yourself... And that
> > > entails taking
> > > down
> > > > prompts that are on the screen when you want a new prompt.
> > > It all becomes
> > > > second nature after a while, and your programs are SO much
> > > more usable
> > > since
> > > > at every point the prompt and the keys available can be 
> displayed
> > > precisely.
> > > > I am absolutely anal about making sure this is always
> > > correct. In other
> > > > words the user of my programs will never see a highlighted
> > > key-prompt if
> > > it
> > > > won't work. In other words if I popup a screen and there
> > > are prompts for
> > > the
> > > > screen under that popup which are not appropriate for that
> > > popup, I take
> > > > down the old prompt and put up the new one.... Even for 
> plain show
> > > messages,
> > > > I clear away non-appropriate prompts which remain. I give
> > > the user no
> > > chance
> > > > intimation that some key might work if it wont. Why?
> > > Because the user
> > > really
> > > > has no idea what a popup is, or a show message, or any idea
> > > at all how
> > > > filePro is really working. If they see something that says
> > > H-hardcopy and
> > > > its not going to work, then it shouldn't be visible,
> > > period.  There are
> > > very
> > > > limited times when I will put up an error message without
> > > clearing away
> > > the
> > > > underlying prompts... But not often.  If you think about
> > > it, you know that
> > > > when an errorbox or mesgbox is up, the only key that will
> > > work is the
> > > ENTER
> > > > key so why leave up prompts like "Press ESC ESC to Record,
> > > DEL to Cancel."
> > > > or similar.  Neither of those keys will work while the 
> message is up
> > > waiting
> > > > for the ENTER key, so I take the trouble to cls("21") just
> > > before putting
> > > up
> > > > the errorbox/mesgbox and then immediately after they press
> > > ENTER I put
> > > back
> > > > up the previous prompt, or whatever is appropriate.
> > > >
> > > > I know the -d key (don't display prompts) has a huge impact
> > > on how the
> > > > application looks, and I know it takes a lot of programming
> > > to put every
> > > > prompt up myself, but if I had to pick the single reason why my
> > > applications
> > > > look like applications instead of looking like "filePro"...
> > > The -d key is
> > > > it. It allows you to provide the definitive touch of
> > > professionalism to
> > > the
> > > > apps you write.  It's worth it.
> > > >
> > > > John
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > > > > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> > > > m] On Behalf Of Richard Kreiss
> > > > > Sent: Friday, January 08, 2010 5:01 PM
> > > > > To: 'filePro List'
> > > > > Subject: popup update * show statements
> > > > >
> > > > > I am moving address fields from the primary data screen in a
> > > > > file.  One
> > > > > piece of information that the record holds is an address.  To
> > > > > make room on
> > > > > the primary screen, I moved the address information to a
> > > popup screen.
> > > > >
> > > > > This screen is editable.
> > > > >
> > > > > Popup update -,"pop_address",24;CLEARP;SAVE
> > > > >
> > > > > @wef24 if:
> > > > > Then: Show 'Enter Name";END
> > > > >
> > > > > Problem: Show statement does not appear.  Just F10-Save
> > > > > ESC-Cancel.  This is
> > > > > not a prompt I am putting up.
> > > > >
> > > > > Anyone know why my show statement is not working?
> > > > >
> > > > > I can replace the show with show popup("18","-1") "Enter
> > > > > Name" and then
> > > > > CLEARS to clear it.
> > > > >
> > > > >
> > > > > Richard Kreiss
> > > > > GCC Consulting
> > > > > rkreiss at gccconsulting.net
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Filepro-list mailing list
> > > > > Filepro-list at lists.celestial.com
> > > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > >
> > > >
> > >
> > 
>