Pop-up killer

Thomas Hayes

Hi everyone
Just a quick question about how others kill previous pop-up pages when you want to have another take its place. I been using '@ppx' followed by a small delay before calling the next popup on. Any sugesstions?

Dries Kaspers

If i remember correctly @ppx kills all popups on all pages. It's better to use either @ppf-<popup_name> to remove a specific popup or to make mutually exclusive popups part of a group so that a ppn command kills all the others.

BTW, a delay is not a must. you can send both commands in the same SEND_COMMAND.

Thomas Hayes

Thanks Dries
The main reason that I was using the @PPX command was because it was the easiest way to kill all the other pop-ups without having to track which one was active.(Getting lazy in my old age). Have you had any problems sending 2 commands without the delay?

Chip Moody

In general, you can pretty heavilly hammer a TP with successive commands and not need to worry about delays. I've seen people issue a zillion variable text commands at the start of a program without a hitch... They've either got a serious buffer in those, or they execute incoming commands >that< quickly... (Maybe a combination of the two)

- Chip

DHawthorne

You can eliminate a lot of the necessity for killing popups simply by grouping windows that never have to be up at the same time. I have at least two groups in every panel design: my main source popups, and my selectors. If I call up a DVD popup, I don't have to worry about shutting down the VCR, the panel handles it internally.

The other thing I do is make heavy use of the fact that you can put multiple page flips on a button press, in bewildering variety. I just recently had a case where I was using a volume button press on an MVP to ppup a volume bargraph - but the customer, being a very immediate kind of guy, was flipping off the page the volume graph was originally on, so the @PPF command wasn't shutting it down. When he went back to that page, the volume graph was still up. So I just added a hide popup to the same button that flipped the main pages.

Which leads to a third point - unless you explicitly designate a page as well as the popup in an @PPF command (not always feasible if it can pop up on multiple pages), if the page flips before the command comes in, the command is lost. So there are times when activating or deactivating a popup in code is subject to timing issues. Likewise for sending variable texts, I might add - if you send them to a page that isn't up yet, or has closed, they don't update. You don't want to stream them all the time either, it does bog the system. So I do track when pages and popups are active, preferably through the channel of the button that fips them on, or, if that is not reliable, through tracking messages from the panel. Then you can only update pages that actually need it.

In any case, my practice is only to use code to flip pages when there is no other way to do it (like context-sensitive controls, reverting to a prior page several flips in the past, etc.). On large systems, using code can add some delay as well, giving the panel a sluggish feel to the end user, whereas having the panel do the flips is always immediate.