Re: [openvrml-develop] Problem with loading openvrml.dll

[Kevin M. <kr...@gm...>]

On Wed, Mar 28, 2012 at 1:57 PM, Braden McDaniel <br...@en...>wrote:

> On Tue, 2012-03-20 at 16:17 -0400, Kevin Moule wrote:
> > Hi,
> >
> > I've started using openvrml-0.18 from the SVN branch and have run into a
> > bit of a problem. It seems that the following function
> >
> > openvrml::local::component_registry::component_registry()
> > (component.cpp:343)
> >
> > will throw an exception if the env. variable OPENVRML_DATADIR is not
> > defined and the registry key HKLM\SOFTWARE\OpenVRML\OpenVRML\DataDir is
> not
> > defined.
> >
> > This constructor gets call as part of the normal global variable
> > initialization due to the follow:
> >
> > const openvrml::local::component_registry
> > openvrml::local::component_registry_; (component.cpp:378)
> >
> > and if it throws it will lead to a low level application startup problem
> > that can't be recovered from easily.
> >
> > I know the work around is to either define OPENVRML_DATADIR or create the
> > registry key, but I don't like either of those solutions since they
> require
> > something outside of the application to function.
>
> Is that all that unusual on Windows?  (Honest question.)
>
> The thinking here is that it's the job of an installer to set the
> registry key appropriately.
>

I think it is the norm on Windows. However, I'm a fan of having an
application
be as independent as possible, and at the very least not relying on registry
keys to be able to get an application started.


> > I'm wondering if this can be considered a bug and perhaps have the
> > constructor changed to not throw an exception if the registry key is
> > missing (and also any fallout from the boost::filesystem code).
> >
> > I've fixed this in my working copy by changing the throw declaration to
> > only include std::bad_alloc and then wrapped the majority of the
> > constructor in a try { ... } catch( const std::runtime_error &) {} to
> > silently swallow the error. I've also attached a patch that might be
> easier
> > to read.
>
> Simply swallowing the error without doing anything about it isn't
> appropriate.  There needs to be a component specification store
> somewhere; without it, you have no node implementations.  How do you
> propose to proceed without node implementations?
>

Throwing from a global constructor doesn't seem appropriate either, there
is no way to recover from that.

I did run into the component store problem. Coming from an early version
of 0.17 I didn't fully understand how component/node split worked. So, I
will need to need to satisfy the component_registry's need for a store, I
was
just hoping to do that at runtime. I'm currently exploring ways to get an
environment variable set prior to the DLL being loaded.

Kevin
-



> --
> Braden McDaniel <br...@en...>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>