// Class: cm.core.propsScheme.PropsSchemeContainer 

Removed: extend public void initializeContainer() : deprecated {
Removed: extend public str getCurrent(str key) : deprecated {
Removed: extend public void loadDrawingSchemes(str systemKey) : deprecated 

//Removed methods are replaced with new methods below

Old: extend public void initializeContainer2(World w=null) 
New: extend public void initializeContainer(World w=null)  

Old: extend public str getCurrent2(str key, World w=null) 
New: extend public str getCurrent(str key, World w=null)  

Old: extend public void loadDrawingSchemes2(str systemKey, World w=null) 
New: extend public void loadDrawingSchemes(str systemKey, World w=null)  

// Class: cm.core.propsScheme.PropsSchemeManager 

Removed: final public bool assignToContainer(PropsScheme scheme, bool replace=false) : deprecated 

//Replaced with new method below

Old: final public bool assignToContainer2(PropsScheme scheme, bool replace=false, PropsSchemeContainer container=null) 
New: final public bool assignToContainer(PropsScheme scheme, bool replace=false, PropsSchemeContainer container=null)  

Removed: public void registerSchemesParent(str[] systemKeys, str parentSystemKey) : deprecated  

// Package: cm.core.propsScheme 
Removed: public class OpenSchemePropertyPropDef extends PropDef : deprecated { }
//Now using PropsSchemeQPPropDef instead (in cm.core.propsScheme)

// Class: cm.core.propsScheme.SchemePainterDialog 
Removed: public bool applyAll=true;
Removed: extend public Snapper{} beforeUserApply(Snapper{} snappers, Space space, World world) {
Removed: extend public Snapper{} afterUserApply(Snapper{} snappers, Space space, World world) {
Removed: private void applyAllCB(Control c) {

// Class: cm.core.propsScheme.SpecificPropsScheme 
Removed: public bool removeEmptyNodes(PropsSchemeUIFactory factory, PropsSchemeData data) {
New: public bool hideEmptyNodes(PropsSchemeUIFactory factory) {

// Class: cm.core.propsScheme.layout.PsLayout 
Removed: extend public PsLayoutAbstractPropertyEntry[] getEntriesFromSection(str k) {
New: extend public PsLayoutAbstractPropertyEntry[] getEntriesFromSection(str sectionKey, str tabKey) {

Removed: extend public PsLayoutSection getSection(str k) {
New: extend public PsLayoutSection getSection(str sectionKey, str tabKey) {

Removed: extend public void addToSection(str sectionKey, PsLayoutAbstractPropertyEntry entry) {
New: extend public void addToSection(str tabKey, str sectionKey, PsLayoutAbstractPropertyEntry entry) {

// Class: cm.core.propsScheme.layout.PsLayoutPropertyEntryUIFactory 
Old: extend public void controlChanged(Control c, str key, Object value) 
New: extend public void controlChanged(Control c, str key, Object value, Object env=null)  

// Package: cm.core.propsScheme.layout.editor 
Removed: public class PsLayoutEditCustomKeyDialog extends SlimCaptionDialog : abstract {
Removed: package class PsLayoutItemTVIEditKeyDialog extends PsLayoutEditCustomKeyDialog {
Removed: package class PsLayoutPropertyEditKeyDialog extends PsLayoutEditCustomKeyDialog {
Removed: package class PsLayoutSectionEditKeyDialog extends PsLayoutEditCustomKeyDialog {
Removed: private void keyEditedCallback(Control c) {
Removed: private void keyApplyCB(Control c) {
Removed: public void closeOpenEditKeyDialog() {
Removed: public void showLayoutItemTVIEditKeyDialog(Window window) {
Removed: public void showLayoutPropertyEditKeyDialog(Window window) {
Removed: public void showLayoutSectionEditKeyDialog(Window window)

//Moved edit key to the PsLayoutEditLabelDialog instead. If you need to control how that is built, please override the following in PsLayoutEditLabelDialog

New: extend public void buildKeyEdit() {

Removal of ensureSettings() call in scheme apply

In 12.0, before scheme apply, to make sure that the props are ready on the target object, we needed to do ensureSettings as prop exposure is typically done there. But it could be very heavy when applying to a lot of snappers, as we don’t need to build the settings, all we need is to make sure the props are exposed.

To counter this, we introduced a validation system for the propDefs, that when called with a certain flag, will call ownerReExposePropDefs to make sure the propDefs are updated.

// In cm/props/propObj.cm: 
/**  
 * Invalidate defs.  
 * Runs validation when propDefs() is called.  
 *   
 * You can for example call this with #reExpose to reexpose registered propDefs  
 * instead of doing it in ensure settings. (implemented in corePropObj)  
 */ 
 final public void invalidatePropDefs(symbol k, Object env=null) {
     ?symbol->Object invalidateDefEnv = propData.?get(cInvalidateDefEnvKey);
     init? invalidateDefEnv();
     invalidateDefEnv.put(k, env);
     if (cInvalidateDefEnvKey !in propData) fastPut(cInvalidateDefEnvKey, invalidateDefEnv);
}  

The issue comes when the propDefs were never exposed/registered before, then there would be nothing to reexpose. In our fix we will need to call ensureSettings the first time if nothing has ever been exposed or registered before.

In the future we plan to have a better fix for this to mitigate the risk of possible calling ensure settings unnecessarily too much.

Some common Q&As regarding the issue:

InitFromPropsScheme doesn’t work anymore, new snappers inserted from toolbox does not get the properties in my selected scheme. What should I do?

We have verified this as a core issue and are working on a fix. If you would like to test it out, try the following:

1.In the constructor of your snapper/object, at the end of it, call ensure settings
2.Insert snapper and see if the problem is resolved. If it is, just wait patiently while the fix is getting tested and merged, otherwise please contact dev support.

I don’t want to wait, there must be something else I can do?

Alternatively, you can do ownerRegisterExposure on your snapper init and loaded1, then your problem would go away immediately.

Change for executePushProps() in PropsSchemePushVisitor

In 12.5, we have refactored the executePushProps() in PropsSchemePushVisitor and PsLayoutPushPropsVisitor to better handling scheme apply for exposed sub objects of a receiver. The change will no longer require exposed sub objects to call pushProps() in its owner.

However, this change could potentially break scheme apply for unexposed sub objects that relied on pushProps(). This is because executePushProps() now calls pushProp() instead of pushProps().

To adapt to this change, we would like to propose using push behaviors for sub objects, here is a step by step guide to setup push behaviors: https://support.configura.com/hc/en-us/articles/14830845427351-Using-PropsSchemes

Using push behaviors would also mean you no longer need to extend pushProps() method just to call pushProps() for sub objects. However, if you encountered any problems on setting up push behaviors, please contact dev support.

Potential issue when init custom scheme on CET start up and the workaround

If you have a custom scheme that is built based on a published scheme design file (*.cmpsl), there is a chance where your scheme might not get init/registered properly if the following scenario matches:

• Catalogue Browser extension is turned on, and
• Catalogue of the published scheme design is turned on (before embed) in Catalogue Details, and
• The published scheme design is activated

If all 3 scenarios mentioned above matches your setup, it is very likely that your custom scheme might get overriden by the Catalogue Scheme registered from Catalogue Browser during CET startup. Here are a few steps to resolve this:

• If the scheme design is not meant to be used in Catalogue Browser, deactivate the scheme design through creator and republish it again.
• In your custom scheme class, when calling dsLoadLayout(), always make sure to pass in activeOnly=false, so we can always get the scheme design regardless of its active status.
• If you are not using Catalogue Browser at all, turning it off should directly avoid this issue.