Hi Eric, As the compiler said, the osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool) method is not static, so just call it from your osgProducer viewer object (viewer->setEscapeSetDone(false)) and it should work.
Cheers, On Mon, Jun 2, 2008 at 4:57 PM, Eric Pouliquen <[EMAIL PROTECTED]> wrote: > Hi, > > i'm using OSG 1.2 on an old project, and i want to switch off the > default "Esc" key behavior (exiting my application). > This project uses a osgProducer::viewer, and i created a class herited of > GUIeventHandler to manage mouse and keyboard events. I can manage all keys > except the 'Esc' key... > Someone said to look at the > osgProducer::KeyboardMouseCallback::setEscapeSetDone(bool), i see in it in > the corresponding code, but how can i use it (a simple call causes an error > due to "non static" style of the function) in my app ? > > I tried to manage the Esc key in the "handle" function, returning true, > and pushing front the handler in the eventHandlerList, but it doesn't work. > > Help :) > > Robert Osfield a écrit : > >> Hi Paul, >> >> On Mon, Jun 2, 2008 at 1:23 PM, Paul Melis <[EMAIL PROTECTED]> wrote: >> >> >>> Doing a diff between the 2.4 and current SVN headers it seems the API >>> changes that break things are minimal: >>> ... >>> So porting from 2.4 to 2.6 (when it comes out) should be fairly easy, >>> unless >>> you do deep stuff with database/terrain paging. >>> >>> >> >> Indeed, even these API changes are unlikely to affect the majority of >> users. In fact >> the 2.0 to 2.2 to 2.4 to the eventual 2.6 are all likely to be >> relatively painless ports. >> >> >> >>> What would be the exact premise for a 2.4 series? Keep the API stable, >>> while >>> only providing bug fixes now and then? >>> >>> >> >> This would be the rough plan - to keep a stable API, and if possible >> binary compatible >> too where possible, and just make stable releases when particular >> fixes are really needed, it might be that the maintainer will just >> declare some fixes as ones that will be dealt with by the next major >> point stable release. >> >> New features I would not expect to be something to roll into stable >> release series, it might be occasional that a bug fix comes with a new >> feature or change in a feature in which case the maintainer will just >> have to show some discretion. >> >> The aim should be to help users that require stable releases, wishing >> to avoid the need for open ended porting to new versions - at most an >> upgrade to a stable minor point release should be a recompile of the >> OSG and their app, this is something that needs to be done >> consistently so users needn't worry about extra porting work coming >> about due to these extra releases. >> >> >> >>> What about additions, like new >>> examples (e.g. osgscreencapture), CMake 2.6 support, threaded HTTP >>> fetching >>> of models? Browsing a bit through the SVN log I think the number of fixes >>> to >>> backport at this point is relatively minor. But backporting for example >>> support for CMake 2.6 might be a bit too much, though (haven't looked at >>> it >>> in detail). The amount of maintenance is therefore directly linked to >>> what >>> you expect a stable branch to contain compared to the development code... >>> >>> >> >> It's support for CMake 2.6 which is one of the motivations for make a >> 2.4.1, as well as the bug fixes. >> >> In terms of making a 2.4.1, we could either use SVN trunk as the >> source and not bother back porting, or do the job by back porting to >> 2.4. Just taking SVN would be quicker and less initial work, but it'd >> introduce new features into the bag that haven't been tested >> thoroughly yet, but then there is always 2.4.2 to fix all the problems >> in 2.4.1 ;-) >> >> If I were to tag a 2.4.1 right now I'd just use SVN as I don't have >> the time to review all the different changes and back porting them to >> 2.4. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> --------------------------------------------------------------------------------------- >> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. >> Aucun virus connu a ce jour par nos services n'a ete detecte. >> >> >> >> >> > > -- > > Eric Pouliquen > > =========================================== > Silicon Worlds S.A. > 224 rue St Denis > 75002 Paris France > Tel: +33 (0) 1 53.90.11.13 > Fax: +33 (0) 1 53.90.11.12 > www.silicon-worlds.fr > =========================================== > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Serge Lages http://www.tharsis-software.com
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
