PG PRO

What I'm doing is looking at the callback routine in Jamin's Navigation services demo. The callback contains code to update FB windows Ð obviously this is application specific but to make a truely usefull filter, it shouldn't rely on update routines which are specific to an app. What I wanted to try was just passing out a message that the windows would need updating, and let the normal update routines do their thing (in my case I always use sep. filters for each window which update the window on a _wUpdate event).

I could of course be wrong about what the call back requires.

You can do what you want as long as the FLTR is BEFORE any window-specific filter:

'============
LOCAL FN sendWndEvent(theWnd,theEvent)
  '===========
  LONG IF theWnd <> 0
    LONG IF WINDOW(-theWnd)
      WINDOW OUTPUT  theWnd
      gActiveDoc   = theWnd
      gOutWindow   = theWnd
      gWhichWindow = theWnd
      gWhichClass  = WINDOW(_outputWClass)
      gAction      = _windowAction
      gSubAction   = theEvent
      GLOBALS GOSUB "End of This Filter"
    END IF
  END IF
END FN

Where "End of this Filter" is a label at the end of the filter. Call the function like so:

FN sendWndEvent(theWnd,_windowUpdate)

I think you are hitting the problem where you are trying to do the updates within the call-back. In the docos, Apple want you to pass the raw events given to you in the call-back to your main event loop. This is a problem because FB/PG apps dont have a standard main event loop.

INVALRECT etc generate an event, but the event is stolen by the Nav Dialog, then given back to you in the call-back! So you must -act- on the update event, not just post another message/event, as it too will be intercepted by the Nav Dialog. Remember that FB/PG is not running an event-loop while you are in a NavServices call, so no "real" OS events will be handled. You should be able to use PGs framework to get around this as suggested by Greg's code.