How to check if CDF-update is necessary?

Hi Max,

There's nothing that really does this. Potentially you could use the functions in the code to run the callbacks on the "effective lookalike" CDF and then compare the results before applying them. In other words, you'd do something like:

cdf=cdfGetInstCDF(instId)
effCDF=CCScreateEffectiveCDFLookalike(cdf t)
CCSinvokeObjCdfCallbacks(effCDF) ; add other args as needed

then you can loop over the parameters of both the cdf and effCDF and see if there were any differences - this way it doesn't really apply any changes - just calls the callback in memory only. This approach will only work if you can get away with using this effective lookalike CDF; if you have CDF callbacks that do strict type checking on their arguments, it won't work.

Note the above is not from testing anything - it's from a quick look at the code (which was written by me, so I think it will work). I have used a similar trick in the past when building hierarchical pcells, where I needed to call the CDF callbacks within a pcell. For speed I wanted to call all the callbacks up front, and then apply all the derived parameters to the pcell instance, to avoid it re-evaluating the pcell for each combination that was found as it iterates through all the parameters.

Regards,

Andrew.

This looks very promising, thanks a lot Andrew!

I compared the values of the parameters in cdf and effCDF and got many mismatches. I took a look inside CCScreateEffectiveCDFLookalike, and when setting the parameters, I see that they're set to their default value instead of their original value. This is done with:

  ; reset the value to defValue for safety
(putpropq newParam (getq newParam defValue) value)

This explains the mismatches I got, since the parameters in cdf and effCDF had different values. As far as I can see, commenting out that line provides the functionality I want. However, why is the parameters set to their default values for safety? 

Regards,

Max 

Hi Max,

The reason was that in the application that I added this for (creating an instance inside a hierarchical pcell, where I needed to call the callbacks), it was a fresh instance and so everything should have been at the default - and I was passing the cell CDF into the CCScreateEffectiveCDFLookalike function. Occasionally if called at the wrong time, the effective Cell CDF can end up with non-default parameters in (I forget the scenarios) and so I wanted to make sure it was reset. I then took the effective lookalike CDF that I was creating, and set the parameters I wanted to set for the child instance, and then called the callbacks on it.

If you're passing in the instance CDF, then you don't really want to reset everything. So maybe adding another argument to the function to not reset would make sense (or just comment out the code).

I'll add that to my list of things to do - to update the solution to the latest version, and to add this parameter.

Regards,

Andrew.

Hi Andrew, 

I agree that an extra optional parameter is the best solution. I'll add it to the my version here for now. Could you also bump this thread when you update the online solution?

I have done some more testing now and your suggestion seems to do everything I want. Thanks a lot!

Regards, 

Max

 Max,

I've updated solution 11018344 to the latest version (it was almost the latest version - I just added this modification).

Regards,

Andrew.

Thanks Andrew, this is doing exactly what I want to do!

Regards, 

Max