It looks like you're new here. If you want to get involved, click one of these buttons!
Hi,
At first I thought the readonly field in a PCell would be a good place to store "user feedback" numbers. For instance, imagine a PCell that draws a rectangle. The PCell code could calculate the area and present it to the user as a greyed-out readonly field in the PCell properties (along with the editable width and height fields) that the user could see for real-time area calculation feedback as they enter numbers.
Of course this is just a simple example. And in this case the area can be reported as the cell name, but if there are several reported values this simple solution starts to not be so great.
Anyway back to the PCell readonly fields. It seems they are readonly in the sense of not being modifiable at all (even by the PCell code, in coerce_parameters_impl), rather than just not modifiable in the GUI. Does it perhaps make sense in a future KL version, as well or instead as these readonly fields, to have certain PCell readonly fields that ARE modifiable by code to report an internal variable, but still without the ability to change it in the GUI? (I get an error if I try to modify readonly values via code.) Otherwise these fields are just reporting a static number that is defined at initialization time, which seems less useful to me.
I could elaborate on certain use cases I have in mind if you are interested or if the idea is not clear.
Thanks
David
Comments
Hi David,
readonly parameters are intended for exactly this case.
They can be modified - the TEXT PCell for example uses this feature to display the effective line width and text height from the character cell's dimensions and the magnification.
Here is an example how to use it. It assumes the code of the sample "Circle" PCell:
This sample shows the diameter in addition to the radius.
But the value is not updated immediately when typing. Instead it is updated when "Apply" is pressed. The reasoning was that I wanted to avoid calling the implementation methods too frequently for performance reasons. Plus I did not want to create interference with user input while debugging the implementation. Maybe that is creating the impression that the value is not updated.
Best regards,
Matthias
You're right, it works! The error I was getting before must have been for a different reason.