Reprogramming a full SDS (however this is done) seems like overkill to me.

Personally, I did a few simple scripts (tied to keystrokes) that allow me to "walk" the object tree for cases like this, like:

• from the currently selected object, go down to the next polygon object below (for the SDS case)
• from the currently selected (polygon) object, go upwards and (de)activate all SDS and symmetry objects containing this poly object

and so on. This method is easier to implement and can be adapted for all kinds of special cases.

@mfersaoui You misunderstand the return value.

This is not a single true/false flag, but a set of flags. As I mentioned, CMD_ENABLED stands for the enabling of the command (greyed out if not set), and CMD_VALUE stands for the checked state (in case of icons, the background changes, as you saw in your test). These two flags are not mutually exclusive but can be used together! (use or to join).

The actual value to use if you want neither flag set is simply 0. False works in this case because the numeric equivalent of false is 0.

import c4d
from c4d import gui

def state():
    op = doc.GetActiveObject()
    if op is not None:
        if op.GetType() == c4d.Ocube :
            return c4d.CMD_ENABLED | c4d.CMD_VALUE
        elif op.GetType() == c4d.Ocylinder :
            return c4d.CMD_VALUE
        else :
            return c4d.CMD_ENABLED
    return 0

# Main function
def main():
    print "Triggered!"

# Execute main()
if __name__=='__main__':
    main()

If you watch the above script as icon in a toolbar, you will see all four state combinations depending on what primitive you select. If nothing is selected, the icon is grayed out. If you select a cylinder, the icon is still grayed out and unselectable but the background changes to make clear it's checked. A cube will show both the checked and active states, and some other object will show only the active state.

To be fair, the standard default script in R20 mentions False explicitly though.

Just food for thought:
I once had the same desire to create landscapes in optimum resolution, but I came to realize that it is necessary to create a dynamic subdivision that reserves the higher resolutions for spots close to the camera. The numbers just accumulate too fast:

Subdivision of 15 means
2^15 = 32768 segments in either direction, which amounts to
32768^2 = 1,073,741,824 polygons (one gigapoly ).
Almost the same number of points is needed to define these polygons
(strictly one row and one line more, so 32769^2 = 1,073,807,361).
Each point is a vector from three floats, which is eight bytes each, resulting in a payload of roundabout 8GB for storing the points alone. Each polygon refers to four points which requires an index of four bytes at least (too lazy to look up the type now), which is another 16GB.

Thus, your plane has a memory footprint of 24GB for (2^15)^2 segments (for 2^17 it's 16 times more, or 384GB). A well equipped machine may still be able to work with that, but it's not practical, and causes inavoidable lags and most likely swapping. Not having a special datatype underlying, C4D may need to copy that data for rendering, too...

Override CommandData.GetState(doc) or ToolData.GetState(doc) to return a combination of
CMD_ENABLED (enabled)
CMD_VALUE (checked)
or neither.

As for SCALE_V, this normally works... but all groups above the GUI element need to have the same property:

CONTAINER Tcommentarytag
{
	NAME Tcommentarytag;
	INCLUDE Tbase;

	GROUP ID_TAGPROPERTIES
	{
		SCALE_V;

		STRING COMMENTARY_STRING { CUSTOMGUI MULTISTRING; SCALE_V; }
	}
}

This way, it works - remove the SCALE_V from the GROUP and it won't work any more (because the group then is sized only to the necessary minimum vertically, and the string field simply doesn't get any additional space as the group has eaten it all up).

That's because there is none. The Windows functionality in the API is very limited. You can open some through CallCommand but identification and handling of specific windows is not supported.

Only thing you could do is loading a new layout.

If I would take a guess, there is a Workplane active. That is the only way I know that can change the apparent directionality of the world coordinate system. Align the workplane to Y to reset it to the normal world.

To take the Workplane into account with any of your plugins, use GetWorkplaneMatrix() to get the needed transformation.

CTrack is a BaseList2D so you can iterate through the list by GetNext().
Then you just need to check the DescID for the proper Id of a CTsound.

import c4d

def main() :
    obj = doc.GetActiveObject()
    if obj :
        track = obj.GetFirstCTrack()
        while track != None :
            descID = track.GetDescriptionID()
            if descID.__getitem__(0) == c4d.DescLevel(c4d.CTsound) :
                print "Hooray! Found a sound track!"
            track = track.GetNext()

if __name__=='__main__':
    main()

One of these days I'm going to understand these DescLevels too, maybe...

You don't need a script for that. When in the Object Manager, look at the menu (File/Edit/View...). There is this point pattern to the left of it that contains the window menu.

Ctrl-leftclick on it, and it folds into a neat bar. Click the point pattern of this bar to unfold the OM again.

I am not aware of a keyboard shortcut for that functionality - and I doubt it would make sense since you need to specify the window to fold anyway, which is done by clicking in this case (thereby pointing the mouse at the desired window).

(You also don't have any window functions in the API, so you couldn't write a script even if you would be content with having as many keyboard shortcuts as possible Object Managers, which IMHO is awkward.)

Without actually trying the code:

1. newLocalPoints is in local space. This is where you zero the y value. Which means that the point will now have a y of 0 in local space.

2. Then you multiply the world matrix with the new positions. BUT: This world matrix is already part of the object that contains the points. Now your points have applied the matrix twice, first through the object and then through this multiplication.

3. While the local y is 0, the multiplication with obj_mat will give the point a global y anyway because obj_mat may contain a translation in space. Moreover, the obj itself does, too. So, your point's y will definitely not be world 0 in the end.

What you really need to do:

1. Determine the world vector for the points (it's only a vector and not a matrix since a point does not contain a rotation or scale). This is done by applying obj_mat to each point vector, resulting in a new vector for each point. Why? Because your object's transformation in space (which is the meaning of obj_mat) is affecting all points in the object's local system.

2. For this global vector, you set the y component to 0.

3. Then you transform this global vector back to the object's local space by applying inv_obj_mat. Note that after this inverse transformation, the local y may no longer be 0!

4. Profit.

Okay, I wrote the script after all. You owe me a beer.

import c4d
from c4d import gui

def set_Y_vector(obj, value):
    oldPoints = obj.GetAllPoints()
    obj_mat = obj.GetMg()
    inv_obj_mat = ~obj_mat

    newWorldPoints = [p * obj_mat for p in oldPoints]
    newLocalPoints = [inv_obj_mat * c4d.Vector(p[0], p[1]*value, p[2]) for p in newWorldPoints]

    obj.SetAllPoints(newLocalPoints)
    obj.Message (c4d.MSG_UPDATE) 
    c4d.EventAdd()
    

def main():
    set_Y_vector(op, 0)

if __name__=='__main__':
    main()