First, the code you show isn't modifying SU's DCFunctionsV1, it is creating a new class of that name within the M123::M123abc module namespace.

Second, what makes you think that just defining atan2 within the DCFunctionsV1 class will make that formula available for use in DC's? That assumes a lot about how the DC class is programmed (which isn't documented).

Thanks a lot for the advice, slbaumgartner and TIG. Will try the codes later.

Another question, if you don't mind. Assuming we do not confine the entire code within it's own namespace (module), will there be a chance that name of the customised formula clashes with someone's else?

If we have created another unique formula for the dynamic component, for example, def qwer(a) and qwer(a)=a[0]+a[1]+a[2]. Is there any way from preventing others from using the same name as qwer(a)?

You have misunderstood the purpose of the ...methods.sort snippet.It is for use in the Ruby Console - pasted manually - so that you can see what's available.The main code that defines the new function should NOT have that added into it !As you have found it breaks it !

You have a script creating the atan2 function.Do not do anything more to that.Do not place it within your own name spaces [for now at least].Use it as my example...Use it to add the extra function directly into the DC code.

There are ways to use an existing class and add to it or 'refine' it etc within your own module[s].But that will provide the new class/method when called within your module - but not outside of it.

Since the DC code is calling its class/method directly, then your own method-wrapped additions will not be seen by it.

Since you are only using this code for yourself [?] I see little wrong in adding directly to the DC class and then making your own separate code within your own module[s] to do other things.The method I provided only adds the new method it it doesn't exist [for example some other code is adding it or in the future it's added to the main shipped class.

It is bad form to mess with shipped classes etc, but sometimes you must do it - e.g. this DC class methods are used directly in the DC functions...

At this moment, I am using the code for myself. However, I am also looking at opportunity to release the dynamic components I have created into the Extension Store.

I have seen the recommendation that you have shared with others in the forum. One way of getting the DC component to be dependent on the plugin is to give the DC component a function defined in the code. The DC component will not work without the plugin.

How can we use the class DCFunctionV1 within the name space (our own module) so that it fulfills the requirement of a good practice of a plugin? This is the question I am trying to get around. Any recommendation on this?

I don't think you can do it wrapped inside your module.It needs to add the function-method to the DC class directly, so that it's then seen by the DC function calling that class.If you define it within your module it's your module's class and will not be seen.Even if you 'refine' it or use it in other ways it's new methods are only seen in your class.You need to change the DC class directly !

Changing a shipped class might get you into a mess on the EWH.You could of course sell it separately...

Since we are unable to wrap the class DCFunctionsV1 in the name space, if we just submit the script with 2 parts, one of which is the DCFunctionsV1 and letting the formula be defined as my own unique name, and the second part which is wrapped within my name space, will this work? Will EWH team accept this?

Will try to submit once I have cleaned up the code. Fingers crossed, but I have a feeling that you are right. It might get rejected.

It will be a pity though, because I believe there are many members who are able to build up the dynamic components (which can speed up and simplify the entire modelling process), but there's no way to prevent the DC from being distributed without the authors' agreement.

Hi TIG, Dan,Is there any resources online that shows how we can input the licensing code to our script? The below web link automatically directed me to another webpage instead of the licensing tutorial.

I said earlier that any code which was altering a 'built-in' class [like the DC's] was like to fall foul of the EW checkers, and of course [thereby] its licensing regime...It would be possible to write a 'non-compliant' extension which did change the DC's class and publish it BUT it can't be downloaded through the EW [there are many other options] - and if it's to be licensed it'll have to be done through another licensing system [again there are several others]...

It is somewhat perverse that SketchUp freely distributes its DC tools, but then does not allow any additions to be made to that code - even with the strictest trapping to avoid overwriting new methods or clashing with other authors - it seems to make the DCs something of an evolutionary dead-end...

After a few rounds of re-submission of my extension to meet the stringent requirements, this time, it is taking slightly longer than usual. I am still waiting for the status of being published in the Extended Warehouse.

In any case, below are some of the screenshots I have created for the extension.