Showing results for 
Search instead for 
Do you mean 
Reply

substitute for UDO dlls loaded at startup

Hello

 

I'm a new user, so please forgive my ignorance.  Also, my company is quite balkanized -- I understand why it would seem strange for me to ask this question here instead of simply asking my coworkers, but that's just the way it has to be.

 

Under our setup, a number of UDOs are contained within DLLs loaded at startup.  This leads to long startup times, and is a hassle when we need to modify those DLLs, because they're stored on a network drive, and locked if anyone has NX running.  Why does this pattern exist?  Are there alternatives to uses of this pattern?

2 REPLIES

Re: substitute for UDO dlls loaded at startup

The UDO dll's need to be loaded at startup in order to register callbacks so that any NX session knows how to handle any user objects defined in a part file.

 

You do not "have" to load these at startup, but if you don't, if a user loads any part containing a UDO into NX, they would not be able to display/query/interact with the UDO. The user would have to manually run code to register the callbacks before they would be able to interact with any existing UDO's or create new ones.

Re: substitute for UDO dlls loaded at startup

OK. Is there a way to "lazy-ize" this pattern, so that the startup DLLs are just lightweight shims that load this functionality on-demand, perhaps from another DLL?