I've only really worked on display programs that output a screen and then wait for input. But it seems to me you can do like the clock you showed, does.

Off the top of my head...For what it's worth...

Your program gets the data ready for the ScreenA, then WRITEs it to the screen (WRITE not EXFMT). Then start a DO loop which does the following:

1. Issues a READ to check whether Sally hit the Enter key. (She's fast).
2. Issue a data queue WAIT to check for changes made to the data Sally's looking at.
3a. If Sally did not hit ENTER, and the data queue shows data changed, refresh the screen with a WRITE.
3b. If Sally did hit ENTER, and the data queue shows the data did NOT change, then accept it and process and all that (mind sending a data queue entry that has the change).
3c. If Sally did hit ENTER, and the data queue data DID change, then handle the conflict however you're going to do it.
4. End the loop.

On 9/2/12 8:21 PM, Booth Martin wrote:
The dataque with trigger is pretty straight forward and provides the
event and needed information. Thats the first half of the problem.

Now, I need the other half, the listening part. Lets say Sally has an
inventory item on her screen and is talking with a customer and the
screen shows:

On Hand - 12
Inbound - 12
Allocated - 22
Available - 2

In the call center there are 28 other folks taking orders and some one
of those people sells 4 pieces, leaving as Available a minus 2.

At this point, I would like Sally's screen to refresh and reflect that
there are none left to sell. All without Sally doing anything and
without a timer constantly refreshing her screen every nn seconds.

This is fairly common in the new world, but it isn't clear to me how we
do this on our platform.

Here is a simplistic example:


This clock refreshes every n.nn minutes, based on a timer. I would
rather that when another program sent a change in the time, a "listener"
would hear the message and poke the clock program with the new time to
be displayed.

An Executive Dashboard is another example of the problem. How does one
refresh that screen by other than a cycle started with a timer?

On 9/2/2012 8:00 PM, Mark S Waterbury wrote:
Hi, Booth:

I think it would help if you could attempt to describe what problem you
are trying to solve, or what you are trying to accomplish. In other
words, what are your goals or objectives.


Mark S. Waterbury

> On 9/2/2012 8:38 PM, Booth Martin wrote:
This seems simple enough yet I am stumbling all over the school yard
with it.

This has to do with event-based actions versus waiting for the Enter key
to be pressed or for a timer to run out..

This is a fairly simplistic case, but it should serve to demonstrate the
problem I am trying to solve.

Lets say a desktop gadget displays the local temperature. When the
temperature changes, the gadget changes the display. As I understand
it, this is accomplished by a "listener" that "listens" for a
temperature change event from the mother ship. It is not a timer that
periodically checks to see what the temperature is. When the listener
hears that the temperature has changed, it alerts the desktop gadget and
my desktop display shows the new temperature. As I said, this is a
simplistic case.

So, in midrange world, how do I mimic the behavior of a listener and of

This may not be well presented. For that I apologize. Of course, if I
understood the issue better I probably would also know the answer,
right? ;) If you have questions, please ask. That may help me
explain my issue better.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page