Best posts made by a_block

Hi,

thanks for the additional information and setting the tags.

The BitmapButton needs to be added to the dialog via AddCustomGui().
For example like so:

        # Prepare a red bitmap for the button.
        w = 50
        h = 50
        bmpRed = c4d.bitmaps.BaseBitmap()
        bmpRed.Init(w, h)
        for y in xrange(w):
            for x in xrange(h):
                bmpRed.SetPixel(x, y, 255, 0, 0)
        # BitmapButton configuration
        bcBitmapButton = c4d.BaseContainer()
        bcBitmapButton[c4d.BITMAPBUTTON_BUTTON] = True

        # Add a BitmapButton to the dialog.
        # _bitmapButton is a member variable of the dialog class
        buttonId = 2000
        _bitmapButton = self.AddCustomGui(buttonId, c4d.CUSTOMGUI_BITMAPBUTTON, "", c4d.BFH_CENTER|c4d.BFV_CENTER, w, h, bcBitmapButton)
        if _bitmapButton is None:
            print "Handle this error!"
        # Assign the image to the button.
        # Note: Let it create an internal copy as the created bitmap will be free'd, when scope is left.
        _bitmapButton.SetImage(bmpRed, True)

Cheers,
Andreas

Hi,

no worries, we'll get you there.

One recommendation: When doing Python development, have the Cinema 4D Console window open (Menu Script -> Console...). There you will be presented with errors.

I think, your problem will be, that you try to access op, probably intending to change parameters of the active object. In Script Manager doc and op are global variables predefined for convenience. In a plugin, you have to get these yourself using GetActiveDocument() and GetActiveObject().

Bye,
Andreas

Hi Kent,

thanks for your feedback.

Actually merging C++ and Python categories was an outcome of our beta phase, where some were of the opinion too many categories would not be desirable. But there's another reason we did so: Our C++ and Python APIs are actually so similar, that many answers hold for both languages.
And lastly, if it were just for the C++ and Python tags, we probably wouldn't even ask for the tags. It's rather tags about version or API in use, we are interested in most.
Oh, and by the way, although I have to admit it was less frequent in the old forum, but instead of asking for tags we were asking to post into the right category. Which by the way still happens with just the four we have here.
Oh, oh... Kent, can you please consider using tags? See About This Forum. Thanks!
Just kidding.

But anyway, these are our reasons, maybe others have different ones and agree with yours. Then please, provide us with your arguments and opinions. It's not that we wouldn't care. We have taken notes of all feedback we received so far and will evaluate this hopefully during November. So, it's actually a good time to provide such feedback.

Maybe we can also address your aversion of "oversized" text. We'll look into providing themes. But we also need to see, what we can actually achieve and maintain in a certain amount of time. After all we think, support work is more important than induldging in web design.
One thing I can say for sure, though. It's not your age. Because with my age increasing I definitely need larger and larger text...

Now, for the community aspect. I'm really sorry to hear this. I can only say, no, it was not our intention to kill the community in Plugin Café. Believe me, quite the opposite. I'd be really interested in more opinions and suggestions on this topic.
Here's how I see it:

• It's always risky to replace a forum, moving the site. And I'm not sure everybody has already joined us here. We had very good reasons for this move and I really hope, everybody will follow.
• With us answering in a day or two on most questions, there's often no more reason for the community to contribute. Looking into the old Plugin Café you will find many thready which took days if not weeks to get an answer from the community. So, I guess, we could revive some community aspects by simply postponing our answers, but I'm not sure that's desirable either.

For example @mp5gosu told us, how much he likes working in this new forum. And we can see him actively discussing and contributing.

Please, everybody, come in, join this thread and provide us with your feedback. Tell us what you want and need. Kent mentioned some good points here. One especially worries me. Help us make this forum the place you want to be supported in. Help us to make this the place you want to discuss your plugin development related topics in.

Cheers,
Andreas

Hi Andre,

you can simply use SetLink(), the opposite of GetLink().

In order to clear a link box, you'd call: self.linkBox.SetLink(None)

The type you do in your code snippet is a bit unconventional in terms of Cinema 4D's API (not wrong though), but usually we recommend to stay in our API for example with CheckType() or IsInstanceOf(). But in the end, I think, you don't even need the type check, if you simply restrict the types accepted by the link box.
For example like so:

bcAcceptedObjects = c4d.BaseContainer()
bcAcceptedObjects.InsData(c4d.TakeBase, "") # only allow BaseTakes to be accepted
bcLinkBox = c4d.BaseContainer()
bcLinkBox.SetData(c4d.DESC_ACCEPT, bcAcceptedObjects)
self.linkBox = self.AddCustomGui(2001, c4d.CUSTOMGUI_LINKBOX, "My Link", c4d.BFH_SCALEFIT | c4d.BFV_CENTER, 0, 0, bcLinkBox)

I turned this thread into a question.

Cheers,
Andreas

Hi,

no your script is not wrong. There's just a bit more to it.

1. To state the obvious, there's no reason, why different tools should have the same ID for a parameter's data, even if these parameters are called identically in the user interface.
2. Just like every other NodeData derived entity, a tool does not necessarily store it's parameters in the BaseContainer. Or it may store values in the BaseContainer, only, if it's different from default. Either way, you have no guarantee to find all parameters in the BaseContainer. Rather use GetParameter() (so in your case for example tool.GetParameter(2108, c4d.DESCFLAGS_GET_0))

Cheers,
Andreas

Hi,

you can also use the Description.

With a small loop, you can get information about a tool's parameters and their type:

    toolID = doc.GetAction()
    tool = c4d.plugins.FindPlugin(toolID, c4d.PLUGINTYPE_TOOL)
    desc = tool.GetDescription(c4d.DESCFLAGS_DESC_0)
    for bc, paramid, groupid in desc:              # Iterate over the parameters of the description
        print bc[c4d.DESC_NAME], paramid[0].dtype  # Print the current parameter name and type

It sounds a bit, as if you try to create some kind of undo system for tools. Something Cinema 4D does not have currently. The standard undo system for example works by cloning instances, something that is not possible with tools. But of course the cloning automatically takes care of the entire instance's state, regardless, if parameters are stored in the BaseContainer or if the complete state is really defined by parameters.
So, just be aware, even with the above approach, there might still be information stored inside of a tool, which may not be reflected by the Description, either. I have no examples for this, it is more a word of a warning, something like this might come up.

Cheers,
Andreas

Hi,

no, you are not!
Really there are no stupid questions and please do not delete such posts. Especially not, if you already invested time in posting the correct answer. We'd rather see this as knowledge others might benefit from in the future.

Cheers,
Andreas

Sorry for joining in so late. And I think, all relevant points have already brought up.
I just wanted to add one twist or slightly different point of view:

c4dpy is a so to say "standalone python interpreter" with access to Cineama 4D's api.

Actually c4dpy is a full headless Cinema 4D, which can be used as a Python interpreter in IDEs.

Cheers,
Andreas

Thanks to everybody in this thread for all your kind words.

@C4DS said in Good Bye and Thanks for the Fish:

As mentioned earlier, this place won't be the same without you.

You may overestimate my contribution. Silently watching from the side line, my feeling is, Riccardo, Sebastian, Maxime and Manuel, though being handicapped by a little loss of man power, not only managed to continue to do a great job in here, but even managed to further improve. Just let the dust of change settle a bit and they'll excel even more.

@C4DS said in Good Bye and Thanks for the Fish:

And with the recent unraveling of the plot, this "ending of your novel" has sure taken a new twist.

I'm not quite sure where you are heading and which plot recently unraveled. But please believe me, my departure was not so much related to Maxon and certainly not connected to any announcements on Maxon's strategy of the recent past. I left a group of friends behind, mostly for private and to a certain extent selfish reasons, which I won't discuss in public. Yet, please, try not to read between the lines and do not interpret my silence against Maxon or the SDK Team. I really enjoyed being part of the ride. Having had the chance to meet all of you in here was really great. It's just sometimes you need to stop eating, when it tastes best. I'm pretty sure Forest Gump also said some fitting words, I just can't remember...

Cheers,
Andreas

Hi,

may I ask you to please add tags to your post (see Read Before Posting)? For example I'm not sure, if you are looking for a C++ or Python solution.

In general the BitmapButtonCustomGui (C++, Python) should do the trick for you.

You can see the usage in our C++ examples:
In a parameter description: objectdata_descriptions.cpp
In a GeDialog: gedialog_gadgets.cpp

Cheers,
Andreas

Hi,

we have the general question, what is the use case of updating a dialog from within the rendering pipeline? This seems pretty unusual to us.

In general you can use Core Messages to execute code in the main thread, see Core Messages Manual. This still works in R20.

In R20 there's ExecuteOnMainThread() in the maxon::JobInterface, see Jobs Manual. But I strongly suggest, that we first discuss, why you want to update a dialog from within the rendering pipeline. Otherwise you'd probably run into unexpected results with this approach.

I turned your thread into a question, see Q&A New Functionality.

Bye,
Andreas

Hi,

you really shouldn't rely on updating a dialog from the render pipeline. You simply do not know, in which context the rendering is happening. For example it could be in command line renderer, which doesn't have a GUI at all.

Instead it would be better to take the result from rendering after it has finished and then update the dialog.

Cheers,
Andreas

Hi,

you have to react to the button in your GeDialog implementation, namely in the Command() function.
See for example these lines in the Py-TextureBaker example.

So picking up my example snippet from above, the Command function could look like so:

    def Command(self, id, msg):
        if id==2000: # corresponds to the button ID used in the code snippet in the first answer in this thread
            print "My Bitmap Button"
        return True

Cheers,
Andreas

Hi Axel,

welcome in our small developer forum.

Unfortunately, it's not the right place to discuss issues with MAXON Labs plugins. This forum is really focused on discussing development related topics with 3rd party developers. The comment you posted on MAXON Labs directly already was the right approach.

The thing with MAXON Labs is, that these are all side projects of our developers, often done in spare time. As the page states, MAXON does not promise any support or future maintenance. With that said, usually our developers provide support nevertheless, just because the want these projects top work ok. But then it also heavily depends on their current workload. I made the developer aware of the issue and it can be reproduced (which is always the first step to a fix), but I can't make any promises when he might find the time to look into it.

Cheers,
Andreas

Hello ello

DescID id;  // Removed

As I said in my previous post DescID has not been removed. I think, it may rather be a problem with a lacking include. Can please check if you do a #include <lib_description.h>?

edit: visual studio now throws this at me
application_Intel_64bit.pdb not loaded

This is just a warning and perfectly normal. We do not provide a .pdb (program database) file for the application itself. These files contain debug information for Visual Studio and would allow inspection of the application we don't want to happen in public.
It is also not related to the startup of Cinema 4D being interrupted twice. We are currently investigating the actual reason for these interruptions and hope to get them fixed with one of the next release. Sorry, for the inconvenience caused.

Cheers,
Andreas

Hi ello,

no, you don't need to worry, the compiler won't check the remaining lines. It is a warning, we use internally to make people write better code. Usually smaller functions are easier to maintain and thinking about how to properly split and slice your code leads to better better results. By the way, compilers nowadays do quite a good job on inlining functions, so one does not need to be afraid of performance issues. But in the end this is probably also a matter of personal taste and so you can configure this in your projectdefinition.txt. See the Stylecheck options in our Project Tool documentation, there you have the option to set the maximum line count for functions (stylecheck.max-linecount=number).

Please consider the use of tags and of our Q&A system.

Cheers,
Andreas

Hi ello,

we are back from DevKitchen, but Riccardo is still busy and I just stumbled across this thread.
Probably he was irritated by the German error message. Actually I think, it's not an exception you are encountering, but just an internal assertion or critical stop, see for example FAQ: Introduction. This could for example happen, if you access a BaseContainer, where you have stored a value with a different type under the same ID before. Maybe RNDOFFSET was used for a different type somewhere lese in the plugin?

Cheers,
Andreas

Hi Roger,

it's always me, who has to bring bad news to you...
Unfortunately this is not possible, the Scale Tool always scales the entire Vector. As evidence you can for example look at our standard Cube and how it reacts to the Scale tool.

Edit: I have changed the thread into a question.

Sorry,
Andreas

Hi Roger,

with respect to the Scale tool, yes, it is impossible to have individual parameters of a custom object scaled non-uniformly.
Of course (but I'm sure you are aware, just mentioning for completeness here) such parameters can be scaled non-uniformly via the Attribute manager. Also you could implement handles for such, so the user can access these via the viewport. And the last option could be to implement your own scale tool.

I'm sorry, I know, none of these options is very convenient, but unfortunately I have nothing better to offer.

Cheers,
Andreas

Hi,

@sgeggie was faster than me...
There's also the Development for macOS page containing some information.
Please note that this behavior changed a bit in Cinema 4D R20 and we are assuming you are looking for information on R20 here.

I have moved this thread into the Cinema 4D Development category. And I also changed this thread into a question and added a tag. Would be nice if you could add another tag regarding the Cinema 4D version you are asking for.

Cheers,
Andreas