I have replied your post at C4DCafe.

"The c4d.documents.LoadDocument returns you a BaseDocument, which you then need as argument for the InsertBaseDocument and SetActiveDocument."

Not sure if this might help or add to the confusion, but in the past I was surprised about this.

I had always assumed a BaseContainer to be similar to what a Python dict represents.
However, the behaviour encountered in above link indicates that next to the key-value, also the sequence of storing the key-values does pay importance in a BaseContainer ... something -if present in the documentation- I always seemed to have overlooked, or missed.

So, doing a compare between two BaseContainers, while containing identical key-value seem to not being equal if those key-value are stored in a different sequence.
Hence "comparing only parts of two BaseContainers" might result in some unexpected behaviours.

In the past the UV editor showed the UVs with origin at top left, as this is also the origin of the UserArea.
Notice that at that point, the UV canvas still didn't have any axis being displayed.
When they started showing the axis (cannot remember if this was R20 or R21 ... I assume R21) they showed the axis the "right" way, with origin at the lower left. Thus actually switching displaying of the UVs in the Y direction.

However, the data is still stored in the old fashion way (origin at top left). Which is what you'll see in the Structure Manager. But internally the Y value is flipped over to represent a lower-left origin in the UV View.

Also note that the values (up to R21 at least) are single precision only.

I guess you encounter the same issue as mentioned here.

Short answer:
When the window has it's own menu then the option's cog wheel should work as expected.
Not so if it is the Finder's main menu.

Which also explains why dropping an icon in the interface does work as expected. As the issue seems to be the main menu in Finder.

I don't think this will work for a Python plugin, but with C++ you can provide a SceneHook and use message MSG_DOCUMENTINFO_TYPE_LOAD

@m_magalhaes said in Mouse positions and screen dimensions:

I need to check the real differences to answer with more details sorry. This is something we need to talk about and document a bit more.

Any news or additional info to share on this?

@m_magalhaes
Do you mean that the fact there is no shadow in case of Windows is seen as a bug and future versions of Cinema4D might fix this issue?
As I am actually looking for a way to get rid of the shadow on macOS, solving this "bug" for Windows would actually introduce an additional drawback.

OK ... so I reinvented the wheel.

# make unique tag name
def makeUniqueTagName(theTag):
    if theTag != None:
        obj = theTag.GetObject()
        # get all names of the tags of same type
        usedNames = []
        if obj != None:
            tag = obj.GetFirstTag()
            while tag != None:
                # skip the tag and 
                # ignore tags of other types
                if tag != theTag and tag.IsInstanceOf(theTag.GetType()) == True:
                    usedNames.append(tag.GetName())
                tag = tag.GetNext()
        # If the name is already taken we will append a dot and number 
        # and increment the number until a unique name is found.
        # Note that since we have created the tag we can assume that
        # the original name does not have a dot and number already.
        suffix = 0
        uniqueName = theTag.GetName()
        while uniqueName in usedNames:
            suffix = suffix + 1
            uniqueName = theTag.GetName() + '.' + str(suffix)
        theTag.SetName(uniqueName)
    return

Maybe not the best nor cleanest code, but then again I am not used to code in Python.
I am sure others might have a better solution, but this seems to work for what I need, so I am happy with how it turned out.

@PluginStudent
Thanks for that.
But that is only when inserting a BaseObject into a document. Still when creating a BaseTag the same behaviour happens behind the scenes, but seems not to be available within the SDK.

As such I can understand the checknames to be deprecated. As a more generic solution would be advised for any naming to be made unique, not only BaseObject.

Hi,
I was wonder if the API (C++ and/or Python) has an helper function to generate a unique name for BaseTag, or any BaseList2D-derived object in general?

Example:
In case you create a polygon selection tag, it's default name is "Polygon Selection". Create an additional one and it will be named "Polygon Selection.1", etc ... Same for objects in the Object Manager.

This seems trivial functionality which is used on different places that I would assume it is a common function used throughout the application, when it needs to generate a default name for an object.

I understand this would be easy to set up one-self by looking up if the default name is already in use, and increment a suffix until the name is unique.
As I am lazy I'd rather use some existing implementation instead of trying the reinvent the wheel.
I just cannot figure out an appropriate function name to perform a search on. Hence I haven't yet found such helper function in the SDK ... if there is one available.