Slave Screen Mode

[Michael Lee]

You might want to make this screen just a regular subscreen. Since you only
pass the 'slave' screen two items which I'm assuming are temporary items, there
is no real reason to call it a slave screen. The SLAVE screens purpose is to
allow a user to enter data a file that cannot fit all it's fields onto one
screen. This is why the mode is so important. There is no other reason to call
a screen a SLAVE screen.

Let me know if I misunderstood the use of this screen.

Michael Lee
MCL Systems Inc.


Terry Pickering wrote:

> I have a slave screen that is a generic "pop up" screen that is called from
> multiple screens in different procedures. Basically the screen is used to
> display a question, then prompt the user for a response. It is used for
> example to ask the user if they wish to continue before deleting records,
> prompt for printer queues, report parameters etc. There are only two fields
> passed to the screen - T-QUESTION and T-ANSWER.
>
> The screen has worked fine and is used quite a bit. I now have a need to
> get a parameter (a PO number) to pass to an inquiry screen PRIOR to them
> actually entering any data on the calling screen. In the previous uses, the
> screen was in entry mode, or an existing record had already been found. In
> this case, I need to get the PO number and call the inquiry screen first so
> they can decide if they want to enter an invoice.
>
> The user executes a designer procedure (which has NODATA on it) and then
> attempts to run the question/answer slave screen. When I run it, I receive
> the error message "*d* Incompatible mode was specified for the slave
> screen". The slave screen has no activity restrictions. I've tried forcing
> the mode by specifying it on the RUN SCREEN command (both FIND and ENTRY)
> and still get the error. It appears that since the initial calling screen
> does not have any "mode set", you can not call a slave screen.
>
> There is not enough room on the screen to add a field for the user to enter
> into. And I'm afraid that if I do an ACCEPT on the PO-NUM field on the
> calling screen, that will change the record status to new. Which means that
> if they decide they don't want to enter an invoice, it will give them nasty
> messages when they backout. I suppose I could write another completely new
> screen that is not a slave screen, but it seems a waste of time for this
> simple need.
>
> Has anyone had similar experiences with this? Better yet - have a work
> around for what I'm trying to do?
>
> Terry P.
>
> Terry Pickering                         CompuGroup, Inc.
> pickering@myself.com                    Portland, Oregon USA
> www.teleport.com/~compugrp              Cessna 172 & Lancair ES
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.