Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-11 Thread Judson Weissert
Robert, On 6/11/2013 5:08 AM, Robert Osfield wrote: Hi Judson, I have just checked in a change to Registry so it now sorts the list of ReaderWrite::ReadResult/WriteResult and returns the last result. The results are sorted on the Read/WriteStatus with these enums now ordered so that the most re

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-11 Thread Robert Osfield
Hi Judson, I have just checked in a change to Registry so it now sorts the list of ReaderWrite::ReadResult/WriteResult and returns the last result. The results are sorted on the Read/WriteStatus with these enums now ordered so that the most relevant status is later so sorted list will give us what

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-11 Thread Robert Osfield
Hi Judson, Thanks for the explanation. The ERROR_IN_WRITING ReadResult really should be the one the bubbles to the top to returned as the most relevant result. So I believe we need an extra bit of code that filters the results list to find the most relevant result. This will require ordering in

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Judson Weissert
Hi Robert, I guess what I am trying to convey is that the successful (FILE_SAVED) code paths works correctly, the Chain-Of-Responsibility for that case works fine (first to succeed wins). The problem is when I try to write a file that is not writable (i.e. try to write to a file that is open b

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Robert Osfield
Hi Judson, On 10 June 2013 21:12, Judson Weissert wrote: > One of the major behavior changes is that once ERROR_IN_WRITING_FILE is > encountered, no more attempts are made to write the file. This breaks the Chain-Of-Responsibility design pattern used by the plugins, it's up to plugins whether or

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Judson Weissert
Hi Robert, Once again, thank you for your time. I continued to look into the scene export issues I was having, and here are some of my findings (against OSG 3.1.7 development release). I attached an alternate implementation of osgDB::Registry::writeNodeImplementation(). The same changes woul

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Robert Osfield
Hi Judson. On 10 June 2013 16:27, Judson Weissert wrote: > First pass, result status is FILE_NOT_HANDLED message is "Warning: Write to > "path" not supported." > Second pass, result status is ERROR_IN_WRITING_FILE message is "Warning: > Could not find plugin to write nodes to file "path." > The f

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Judson Weissert
Hi Robert, On 6/10/2013 4:48 AM, Robert Osfield wrote: Hi Judson, When you say the WriteResult is different could you explain what the result is in each case? Is there file written out OK in ech case. First pass, result status is FILE_NOT_HANDLED message is "Warning: Write to "path" not suppo

Re: [osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-10 Thread Robert Osfield
Hi Judson, When you say the WriteResult is different could you explain what the result is in each case? Is there file written out OK in ech case. W.r.t binary planting, the most secure way to avoid any plugins being loaded that aren't purka is to build your application as a static binary with al

[osg-users] [osgDB] Registry::writeNodeImplementation()

2013-06-07 Thread Judson Weissert
Hi, I was working on OSG export related code and I noticed some interesting problems with osgDB::Registry::writeNodeImplementation() and other similar functions within Registry.cpp. The first issue is that performing the same task twice gives different result. Reproduction case: 1. Create a