FB II Compiler

PG PRO

Debugging

Memory

System

Mathematics

Resources

Disk I/O

Windows

Controls

Menus

Mouse

Keyboard

Text

Fonts

Drawing

Sound

Clipboard

Printing

Communication

ASM

Made with FB

PG PRO

Fake an update event in PG


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.

David

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)
Greg

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.

Jamin