Introduced a new callback osgDB::FindFileCallback that overrides the default behavior of findDataFile/findLibraryFile.
Introduced support for assigning ReaderWriter::Options directory to PagedLOD.
Introduced new osgDB::FileLocationCallback for assistancing the DatabasePager to know when a file is hosted on a local or remote file system.
Introduced a new FindFileCallback to Registry to compliement the existing ReadFileCallback and WriteFileCallback.
Added support for assign Find, Read and WriteFileCallbacks to osdDB::Options to enable plugins/applications to override the callbacks just for that
read/write call and any nested file operations
Original email from Frederic at start of thread:
"he patch attached, made from r10068, fix two things, in other of importance :
- the selected cursor is never shown ( second change in file ). Only the left arrow is always displayed.
- remove the arbitrary ( in my sense ) limitation that the user cannot choose a cursor with the same shape that one used when resizing the window. This limitation doesn't exist for X11, and we have a diverging behaviour there ( first change in file ). Flightgear use the LeftRightCursor in look around mode."
Follow up email from Frederic (with changes that finally made it into this check in:
"I've just tested Mark's suggestion and it works perfectly, even when the
cursor goes to the border then come back inside the window.
But his patch doesn't seem to be based on the last revision of the
files, or at least not on the trunk, and there are more changes than
expected in them, including some loss from the previous patches.
The patch attached is based on r10068 of
src/osgViewer/GraphicsWindowWin32.cpp and r10067 of
include/osgViewer/api/Win32/GraphicsWindowWin32"
the conditional directives for setting the prepend-string in
createLibraryNameForExtension were not in effect, because of the mixture
of different #ifdef styles.
I removed the conditional part for __APPLE__ completely to be more
standard-conform with other platforms (plugins should be located in
osgPlugins-X.X.X/). Because of the wrong syntax of the conditional
compile the old code was not used anyway -- so no functional change.
"
So, might be a bit fiddly to try and prevent frame update in all situations that SwapBuffers retuns false.
I wondered if we could address this issue by only reporting the error if GetLastError is also non zero. Works for me!
The value returned by GetLastError is zero when SwapBuffers is called for a minimized or off screen window, so we could just add a check for this.
Just say the word, and I'll post my modified GraphicsWindowWin32.cpp to the submissions list. ;-)
Cheers.
Chris.
e.g.
//------------- OSG- 2..8 ----------
void GraphicsWindowWin32::swapBuffersImplementation()
{
if (!_realized) return;
if (!::SwapBuffers(_hdc))
{
reportErrorForScreen("GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers", _traits->screenNum, ::GetLastError());
}
}
//------------- Modification to remove redundant warnings ----------
void GraphicsWindowWin32::swapBuffersImplementation()
{
if (!_realized) return;
if (!::SwapBuffers(_hdc) && ::GetLastError() != 0)
{
reportErrorForScreen("GraphicsWindowWin32::swapBuffersImplementation() - Unable to swap display buffers", _traits->screenNum, ::GetLastError());
}
}
"
"the latest SVN revision cannot be build under Windows if ?OSG_USE_UTF8_FILENAME? config option is enabled. The error occurs in ?FileUtils.cpp? file, line 663, since there is no UNICODE-capable version of the ?GetProcAddress? function. The ?OSGDB_WINDOWS_FUNCT_STRING? makro is defined as follows in that case
#define OSGDB_WINDOWS_FUNCT_STRING(x) L ## #x L"W"
Thus the second parameter cannot be converted from wchar_t to LPCSTR. Should we convert the second parameter from wchar_t* to LPCSTR or use the same definition for the ?OSGDB_WINDOWS_FUNCT_STRING? makro in both cases?
The second error occurs in the same file, line 669. The second parameter for the ?pGetModuleHandleEx? function should be defined as wchar_t, but it?s defined as ?static char static_variable? in the line 667."
