Hi Guys,
I'm currently compiling a couple of change that will hopefully catch
undefined screen settings slightly higher up - in the
GraphicsContext::createGraphicsContext(Traits*) call.
I've also added a new GraphicsContext::ScreenIdentifier method, and
extra details about the undefined screen num policy that readDisplay()
uses. The new method looks like:
/** Set any undefined displayNum or screenNum values (i.e.
-1) to the default display & screen of 0 respectively.*/
void setUndefinedScreenDetailsToDefaultScreen()
{
if (displayNum<0) displayNum = 0;
if (screenNum<0) screenNum = 0;
}
I'll check this in once things are working.
Robert.
On Jan 4, 2008 11:28 AM, Robert Osfield <[EMAIL PROTECTED]> wrote:
> Hi Tim,
>
> On Jan 4, 2008 11:20 AM, Tim Moore <[EMAIL PROTECTED]> wrote:
> > I couldn't find one. There is some code in osgViewer/View.cpp to deal with
> > the case in
> > setUpViewAcrossAllScreens(), which is probably the common code path for
> > osgviewer. I
> > suspect that you hit the problem if your application initializes a Traits
> > structure and
> > creates a graphics context itself.
>
> If the catch blocks in osgViewer::View aren't been used then the only
> place to catch this case is within GrpahicsWindowX11, Win32 and
> Carbon, this should be a straight forward addition though. I believe
> added entries to these is better than hacking the catch for when no
> screen number is defined, -1 is deliberately used to tell the
> developer than the DISPLAY string didn't explicitly specify a screen
> number, remove this and you also remove the ability for the
> application developer to do their own handling of the fallback.
>
> Robert.
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
