Thanks for looking into this. It is not so crucial to hide the handles - I will try the custom GUI approach as you suggest.

so we talked about it and it is unfortunately as I said, you cannot hide that handle. So for now you would have to provide your own CustomGuiData . @m_magalhaes however pointed out that in R19 or prior, not only the step interpolation mode came with no handle, but also the linear mode. Which in in conjunction with NOINJTERPOLATION would probably get pretty close to what you want. We will investigate if that change was intentional or not. But considering how old these changes are, it seems rather unlikely that we will fix it even if consider it unintentional, due to the breaking of compatibilities that would imply. We might introduce a new interpolation mode then which mimics the old linear mode, but that is only a faint possibility, not a guarantee.

For now the only option for you is unfortunately CustomGuiData .

Thank you for your understanding and cheers,
Ferdinand

so you want to get rid of the actual GUI handle, not the edit field? You can usually test this stuff with the user data editor, with which you can try out the different combinations of flags and their effects for the different custom GUIs. Since none of them does what you want to do and I do not see any other "secret" flags, I would say it is simply impossible to hide the bias handles (other than by changing the inpolation type to step). I will talk about it with the others tomorrow, but at least I currently do not see a way to do it. If this is crucial for you, you might have to implement this yourself as your own CustomGuiData for the gradient data type.

Maybe the others have a light bulb moment, but I would not get my hopes up

Cheers,
Ferdinand

Thanks for the fast response. I'm trying to add this gradient to a Shader node. As I mentioned - adding the suggestion from the #define comment in the .res file did not yield result.
Sorry I was ambiguous in my second part - by description I meant that I also tried setting the constant as container data in the ShaderData::GetDDescription(..) function override that I implemented in my shader. Something similar to this:

Bool MyShader::GetDDescription(GeListNode *node, Description *description, DESCFLAGS_DESC &flags) {
	if (!node || !description) {
		return SUPER::GetDDescription(node, description, flags);
	}

	if ((flags & DESCFLAGS_DESC::LOADED) == DESCFLAGS_DESC::NONE) {
		if (!description->LoadDescription(ID_MY_SHADER)) {
			return false;
		}
		flags |= DESCFLAGS_DESC::LOADED;
	}
	BaseContainer *gradientContainer=description->GetParameterI(MY_GRADIENT, nullptr);
	if (gradientContainer) {
		gradientContainer->SetBool(GRADIENTPROPERTY_NOBIASPOSITION, true);
	}

	return SUPER::GetDDescription(node, description, flags);
}

Thank you for reaching out to us. We will properly answer your question tomorrow, but it might be helpful if you would provide us with the place where you are doing that. You talk about description, which, well, implies a description. This should work. If you were however talking about a dialog resource, defined in a res file, I would not be surprised about you having problems, since some elements are a bit wonky in GeDialog resources. So it would be nice if you can confirm that you are in a node/description.

Cheers,
Ferdinand