they are just static variables in the cpp or h file. i did find a way now around it. i am using the DllMain on windwos. Which is exactely what i need. It runs once when the dll gets loaded and everything is setup at this point. That is only a windows solution as its a dll specifc thing. For linux i would still need to get that static globals class going.
to be a little more prcise... in my static globals class i use funcions that themselvs include a custom string class this one has static varibles defined that those are NOT valid when my globals class is instanciated. On Wed, Dec 17, 2014 at 3:10 PM, Colin Doncaster <[email protected]> wrote: > If the static members aren’t initialized when the DSO is loaded (which > seems like a bad design decision), then there has to be some method of > MYSOFTWARE you need to call to initialize them - right? > > > On Dec 17, 2014, at 5:12 PM, Johannes Saam <[email protected]> > wrote: > > hey! Thanks for the quick reply! > > basically i am trying to ingerate nuke in a system that itself consists of > lots of plugins. > > i need to in pseudo > > load plugin > initalize MYSOFTWARE > register plugins etc > > create node > register node in MYSOFTWARE > rename node emit rename to MYSOFTWARE > do stuff > delete node > delete node in MYSOFTWARE > > right now i have one Op and my setup wrapper. The setup wrapper itself > calls code in MYSOFTWARE that contains static members. > when my static globlas class is called the static members of MYSOFTWARE > are not initialized. > maybe i am just doing it wrong but it looks something like this > > class globals > { > globals() > { > stuff happens; > } > }_globals; > > > > myOp...... > > On Wed, Dec 17, 2014 at 1:56 PM, Colin Doncaster < > [email protected]> wrote: > >> The static class should be fine, I’m not too sure what you mean about >> the order issue of the static variables? If you encapsulate everything >> into a single static Globals class then you’ll end up with a tidy solution. >> >> Without knowing exactly what you’re trying to do you may want to look at >> implementing a singleton pattern that provides a little more managed glue >> between Nuke and whatever you’re trying to integrate. >> >> Just be aware about symbol visibility if building multiple nuke nodes >> that use the same static globals. >> >> >> > On Dec 17, 2014, at 4:37 PM, Johannes Saam <[email protected]> >> wrote: >> > >> > hey Nuke dev! >> > >> > I have another strange one... i need to setup stuff on plugin load. >> > What is the smartest way to run code ONCE when the plugin gets loaded? >> > >> > i researched and so far i am using a static object and in its >> constructor i do my business. the problem that i am facing is that the >> order of static objects is not defined. So now in my static setup class i >> am calling code that itself has static variables and they are not valid at >> this point. >> > >> > I am looking for the equivalent of initializePlugin in maya for >> example. A space that is valid but only run ONCE as SOON as you load the >> plugin. >> > >> > Overall i need this and then a space on node create and delete ( i have >> found the attach and dettach methods to work fine here ) as well as a node >> renamed callback. This callback works fine now but really due to the >> unpredictable order of static variables i would need some help with the >> plugin initialize. >> > >> > Any code masters out there with new ideas? >> > Rock on >> > jo >> > _______________________________________________ >> > Nuke-dev mailing list >> > [email protected], http://forums.thefoundry.co.uk/ >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > >
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
