[osg-users] avoid Esc key on keyboard

[Serge Lages]

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 <epouliquen at silicon-worlds.fr>
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 <paul at science.uva.nl> 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
>> osg-users at lists.openscenegraph.org
>> 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
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Serge Lages
http://www.tharsis-software.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080602/854c69ff/attachment.htm>