SHADERLINK interfering with COLUMNS in description

Helper

On 19/08/2016 at 02:19, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R17
Platform:   Windows ;
Language(s) :     C++ ;

---------
I working on GUI for one of my tags and I am trying to create REAL number with some presets next to it (similar to Focal length in C4D camera). This work's without problem when the description contains only simple components, but once I add SHADERLINK, it creates space after column with REAL number (see image). Here is my code for description:

CONTAINER Tmytag
{
    NAME Tmytag;
    INCLUDE Tbase;
  
    GROUP ID_TAGPROPERTIES
    {
        COLUMNS 3;
  
        REAL MY_VALUE { MIN 0; STEP 0.1; }
        LONG MY_PRESET
        {
            CYCLE
            {
                MY_OPTION_1;
                //...
            }
        }
        STATICTEXT { SCALE_H; }
  
        SHADERLINK MY_SHADER { }
        STATICTEXT { JOINEND; }
        STATICTEXT { JOINENDSCALE; }
  
        // Some other elements
    }
}

Image:
https://docs.google.com/uc?id=0B7g1HtV8lD7gWFp6UjQ3MDVKQTg&export=view

The only way I managed to get rid of that space was adding SHADERLINK to separate group (e. g. GROUP { SHADERLINK MY_SHADER { ... } }), but that will break/restart padding of all elements that are after this group (i mean width of automatically generated DescriptionPropertyGui/s).

Is there any way to get rid of that space?

Helper

On 22/08/2016 at 03:12, xxxxxxxx wrote:

Hi,

unfortunately I'm not aware of any means to fix this. All you can do (and seem to already have done) is reorganize your description, but as you already mention, this may have other side effects.

Helper

On 26/08/2016 at 02:54, xxxxxxxx wrote:

Hi,

thanks for answer. I'll wrap shaderlink in single group and try to find a way to enforce controlls after shader to have correct offset.

Just out of curiosity, what is the technical reason for this behaviour? I noticed something similar happens when I use any custom GUI (including my own) instead of shaderlink. C4D can sometimes really suprise with its behaviour in descriptions... it would be helpfull to have some better understanding of how descriptions are used to construct dialogs (if that actually happens that way) so we could actually predict how will things look before trying it in every C4D version...