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,

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

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,

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

Dear fellow developers,

my seasonal greetings to the entire community.

But I'd also like to take the chance to say thanks to "our" SDK Team, who served us so well during the entire year. Patiently answering even my most stupid questions, as if they had nothing else to do (which of course they most likely have)...

So, please, everybody in this community join me in saying:

Thanks for supporting us so well, Riccardo, Sebastian, Maxime and Manuel!

Everybody hopefully gets some well deserved days of rest.

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

Hello Ferdinand,

yes, I was talking about the plugin ID argument of GeDialog.Open() and Restore().

Thanks for your explanation.

I'm completely fine with your answer, despite some seeming here and there. I do understand the problems a codebase grown over decades can cause for answering such questions definitely. Nevertheless your explanations largely sync with my expectations from quite a few experiments.

Regarding the mentioned issue of the other thread, I can acknowledge, the plugin ID parameter did not seem to have influence on the issue in my experiments. This question here was really more targeted the sizing issues I have with requesters of varying content. And your answer provides me with some confidence, I can make use of different plugin IDs (I should probably rather say unique IDs from Plugin Café) even if they are not related to any registered plugins at all. While I had already thought so and did not find any issues with this practice, it's always a bit hard to know for sure from the outside. And there's always this feeling one could be doing something harmful, which will only bite at the worst possible point in future.

Thanks for the clarification.

Cheers,
Andreas

Hi Ferdinand,

thanks for your extensive testing. I feel a bit sorry for having this brought up. Also I wouldn't have expected it to be that hard and specific to reproduce, because here in my R21 chances for it to occur are not that low. Anyway, I can confirm, you are doing the exact right steps to reproduce it.

As almost always with my work, in the end I need something working on multiple versions of C4D. So during the weekend I restructured some parts, to get those requesters out of CoreMessage() as much as possible. And where this was not possible, I went back to the good old standard requesters (c4d.gui.MessageDialog()). So far, this workaround seems to hold. Fingers crossed.

So, from my side, you can almost consider this closed. It's completely up to Maxon, to judge if this may or may not point to some internal issue. And given the fact, that also on my system it seems way less reproducable in S24 (also here on my system), I can fully understand, that there are other more pressing priorities.

I said "almost considered closed", because I'd like to ask two more questions in the context of this issue:

1. Probably most important for me: There is nothing inherently wrong with my approach of opening requesters from CoreMessage() (when paying attention to some rules, like using a specific custom message,...)?

2. This may already be considered off topic, let me know, if I should open a separate thread. Could you provide a bit more info on how the Plugin ID parameter is used by GeDialogs? I mean, the golden rule seems to be, when you open a GeDialog from a CommandData, the CommandData's plugin ID gets passed here. Fine. But what if not? If a GeDialog gets opened from another GeDialog? Or like in my case from a MessageData? Is passing zero ok? Is passing a unique plugin ID, registered only for this purpose ok, even if it is not related to a registered CommandData? One thing C4D seems to use the ID for is to store size information. Which can already be a bit annoying, if like in my case, this dialog is used as a requester with varying content, because once it was opened with some more content, it will remain large, even when displaying less content later on. But ok, that's just cosmetic (though I was thinking to register a bunch of plugin IDs to mitigate this issue). But I could imagine the plugin ID to be used for more serious stuff as well. Like managing contexts or event loops. So long text, short question, can I do harm with this plugin ID?

Cheers,
Andreas

Hello Ferdinand,

1. Yes, I can reproduce it way easier in R21.
2. Correct. I even removed Redshift. Only above demo plugin is installed and running.
3. Nope, no "performance tools". Only MSE/Windows Defender and Windows Firewall as protective tools.

Cheers,
Andreas

Edit: And please take your time. No stress. In the end, whatever the outcome of this thread will be, I will need to find some kind of solid workaround anyway. It will need to work in R19 to S24+ and most of these versions will never get any fixes anymore.

Good morning Ferdinand,

you guessed perfectly right, here in my plugins DialogRequester is basically a more generic and versatile replacement for c4d.gui.MessageDialog() and c4d.gui.QuestionDialog(). Thus the implementation of a static OpenModalRequester()function. It's used all over the place and so far worked very nicely, until I stumbled about this issue, trying to use it in CoreMessage().

I tested your piece of code, unfortunately as we both expected, it doesn't make a difference. We can probably exclude any fears about Python's cleanup being an issue here.

One question though:
In your _openModalRequester() function, how do you derive not being in main thread, simply from checking if the dialog instance exists or is open? I can't follow your logic in the comment. After all it is more or less a static function. Even if implemented as member function, it could be called everywhere and in arbitrary context. But maybe this comment is to read only in the isolated environment of this example and other cases are simply not considered.

And lastly here is a vastly simplified example. Actually the MessageData is not even needed. Neither the intermediate popup dialog. It is enough to send the event to 'DialogMain.CoreMessage()'. The chances are a definitely lower, but I get C4D to lock up this way as well, need maybe ten to fifteen clicks.

Simplified version:
TestDialogFromMessageData_3.pyp

Cheers,
Andreas

Edit: Actually this last finding (issue also occurring with a CM send directly to the dialog itself) is quite funny. Because in the previous version of the example there's the button sending the CM directly to the MessageData ("Send CM dirctly (no issue)") and with this I am not able to get C4D to lock up. But my assumption now is, actually it has a chance to lock up as well even if ever so small for whatever reason. At least I see not real difference between CoreMessage in dialog or MessageData.

Hi Ferdinand,

in the original code this global variable does not exist. I am roughly aware of the intricacies of global variables and try to avoid them as much as our cat avoids water (for those not so familiar with cats: pretty much). It was more a sign of desperation, I added it here today, while experimenting and playing around. In the original code the dialog is actually just held in a local variable of the static global function. As it is modal, the dialog should not be needed anymore after Open() returned. But sure I will test your code as soon as I get back to work tomorrow morning.

Thanks for the suggestion and still thinking about my problem.

Cheers,
Andreas

Hi Ferdinand,

I'm sorry. Unfortunately I can not close this thread, yet. I honestly do not know, what's going on.
So, yes, my S24 does not expose the issue currently. This is with the actual plugin under development (not the example provided here) and after removing and re-adding all plugins. I shouldn't have left this my only test. It seems to have lead me into the wrong direction. Yet, I was so happy...

So the removal of plugins lead me to the hypothesis, that I have some interdependency in my own plugins, which may have fixed itself due to perhaps another load order.

I did not see any potential in the various MessageData components, though, but suspected something else:
Yes, here I have to admit (and I am aware, we are not supposed to be doing this), my plugins are separated into multiple submodules. So I am indeed polluting sys.path (and am aslo reloading modules in 'C4DPL_RELOADPYTHONPLUGINS'). To my excuse, with projects of a certain size I see actually no other option. Anyway, my plugins indeed share a bunch of code in various utility modules and I suspected this to be the cause of all my misery.

But by now, I am pretty sure, this is not the case anymore. Even worse, when going back to R21, the problem was there again, immediately. So I started removing plugins there again. And after removing all plugins except the above posted test example, it does still happen. And here it really happens quite fast and reproduceably. Most of the time the first time I click Cancel in the modal requester. During a row of ten consecutive tests, most of the time it happened during the first three click cycles, at most I needed five.

By the way, something I hadn't mentioned before: C4D is not only locked up, but burning on one CPU core, so my educated guess would be C4D is spinning on some spin lock, though of course it may as well be caught in an infinite loop (please lets not discuss, if spin locks belong into the set of endless loops).

Taking into account, that it only happens with a certain chance, it obviously also is some kind of race condition. Which may also explain, why small changes to the "C4D ecosystem" (i.e. removing plugins) are capable of masking the problem. And in the end CPU speeds and number of cores most likely have this potential as well. Here it's running on an quite old Intel Core i7-3930K (6 cores, 12 threads).

Nevertheless, after having spent all day with this issue, I am quite sure, the above posted code is either doing something really sinister, or, if what is does is in the realm of things we are allowed to do, then there is some issue in C4D. Most reproduceable it is in my R21. In S24 I admit, with only above test plugin in the system I can still no longer reproduce this. But I am sure, I saw it in S24 as well before, so maybe due to different runtime characteristics it is just way less likely... who knows. I could as well be wrong though, and in S24 it was a different issue in my code, which got implicitly fixed by now.

During my experiments I have further changed the example code (e.g. removed use of DialogPopup.Message(), added more buttons, to play with different ways to reproduce, removed flags not needed for reproduction, increased button sizes so Manuel could rapid fire them more easily, adcded a second CommandData to host the popup dialog...). So far, I can reproduce it only, with the intermediate popup dialog, regardless, if this popup dialog gets spawned directly from main dialog or by use of the second CommandData to own the popup dialog.

This is the part that worries me most. Could it be, the real issue is not opening the modal dialog from MessageData.CoreMessage(), but there is something wrong with spawning another asynchronous dialog from an asynchronous dialog? But I only noticed this for whatever reason due to increasing the chances for the issue via the modal dialog spawned by the MessageData? Which in the end would mean, I have a completely different and way more serious issue in my plugin lingering around. It just went by unnoticed until this dreaded modal dialog came into play...

Anyway, here's the updated version of the test plugin, just in case somebody still feels motivated to look into the issue:
TestDialogFromMessageData_2.pyp

Sorry to be a nuisance.

Cheers,
Andreas

Edit: One more finding: Once I make the popup dialog modal (which would basically destroy my workflow) the problem seems also no longer reproducable.

Edit: I was shooting too fast. I also got it with a modal popup dialog.

Hi Ferdinand,

very kind, thanks

The click speed, as mentioned in my first post, is not relevant. I can reproduce it here, leaned back, having a cup of coffee between the clicks.
It is actually pretty funny. In S24 I'm no longer able to reproduce it anymore, since I had removed all other plugins, but then re-added them one after one. Problem still gone... and this made me think. Actually you made me think, something I can't tell you how grateful I am for. By now I have a hypothesis of what is going on here. A bit too early to make my incompetence public. But as soon as I have proven my theory right, I'll report back here and explain in detail, to hopefully prevent others from falling into the same self inflicted pit...

I'll be back!

Uh oh...
Good news, indeed with all other plugins removed, I can not reproduce it in S24 either.
Of course good depends on the eye of the beholder... for you it's probably not so good, as I have wasted your time. Sorry for that. Yet, for me, it means, I can continue to search for the cause of the issue on my end. And this to me is good in a way...
Cheers

Hi Ferdinand,

thanks for your quick reply. I'm aware of the consequences of modal dialogs, actually that is the behavior I expect and want to achieve there. The use of the requester in NodeData:Message() is not planned. And I'd happily move that requester out of CoreMessage(), but it needs to happen in response to some threaded stuff going on in background, thus the requester call actually went into MessageData.CoreMessage() as I expected this to be the correct way to get into the main thread, being allowed to do UI stuff there. The above example with the event being posted directly from the popup is only a very simplified version for the purpose of reproduction.
Funny, it can not be reproduced on your end. Here it happens quite reproduceably, latest after five to ten times going through the described sequence.

I will check my installations in regards to possibly interfering plugins. Though R21 and S24 installations are already pretty different in this regard, so I have no high hopes. I'll report back, if I find anything.

One more note, the CoreMessage itself works nicely without issues. Only when the modal requester comes into play, the problems start.

Thanks again, cheers

Hi,

I have an issue with opening a modal dialog from a MessageData's CoreMessage().
There's a certain chance, this locks up C4D completely.

The problem occurs here in R21 as well as S24, both on Win10.

MessageData.CoreMessage()gets triggered by SpecialEventAdd(custom message id) from another dialog and is then supposed to show a custom modal requester.

I have the feeling, the issue may be related to this thread.

Yet, this thread never seems to have come to a conclusion. Also the suggested workaround (ExecuteOnMainThread()) is neither available to me in Python, nor does it seem to be a "main thread issue" as I test for this.
Also I always thought, using SpecialEventAdd()/CoreMessage() the way to transfer execution context to the main thread, also documented C++ docs here and here. Are there any changes to this during latest releases.

Here's some code strapped down from the actual plugin. I tried to provide additional information, about different things I have tried already in the comments of the example.

Please note, when using the example. The problem only has a certain chance to occur. So you may need go through the sequence "Open Popup"->"Press Me"->"Ok" in modal requester several times. No hectic clicking needed, all steps can take there time.

I really hope, somebody finds out, that I'm just massively stupid (which I confess to be anyway, regardless of the outcome of this thread) and need to simply change a line of code, because the actual set up or combination of dialogs is quite crucial for our plugin and its workflow.

In brief the code below does the following:

1. CommandData opens DialogMain in Execute()
2. In reaction to button press, DialogMain.Command() opens DialogPopup
3. In reaction to button press, DialogPopup.Command() calls SpecialEventAdd()
4. In reaction to event, MessageData opens modal dialog in CoreMessage()

Thanks for any help in advance.

Cheers,
Andreas

Here's the code:

import c4d

PLUGIN_ID = 1234570 # MAKE SURE TO USE A UNIQUE IF FROM Plugin Café
PLUGIN_ID_MSGDATA = 1234571 # MAKE SURE TO USE A UNIQUE IF FROM Plugin Café
PLUGIN_ID_COREMESSAGE = 1234572 # MAKE SURE TO USE A UNIQUE IF FROM Plugin Café
PLUGIN_ID_POPUP = 1234573 # MAKE SURE TO USE A UNIQUE IF FROM Plugin Café
PLUGIN_ID_REQUESTER = 1234574 # MAKE SURE TO USE A UNIQUE IF FROM Plugin Café

ID_BUTTON = 1001


def OpenModalRequester():
    if not c4d.threading.GeIsMainThread():
        print('We are here, so the issue would be understandable...')
        # Fortunately, we never end up here.
        # Otherwise would have meant wrong understanding of SpecialEventAdd() leading to main thread.
        return

    dlg = DialogRequester()

    # Being unsure, which plugin ID to pass to subdialogs, I tried PLUGIN_ID, PLUGIN_ID_MSGDATA as well as a unique PLUGIN_ID_REQUESTER.
    # Unfortunately without any effect on the actual issue.
    # Assumption is, for modal or temporary dialogs plugin IDs won't matter much and are only used to store and retrieve size info.
    dlg.Open(dlgtype=c4d.DLG_TYPE_MODAL, pluginid=0, xpos=-2, ypos=-2, defaultw=0, defaulth=0)


class DialogRequester(c4d.gui.GeDialog):

    def CreateLayout(self):
        self.SetTitle('Modal Requester')

        self.AddDlgGroup(c4d.DLG_OK)

        return True


    def Command(self, id, msg):
        if id == c4d.DLG_OK:
            self.Close()

        return True


class MessageDataTest(c4d.plugins.MessageData):

    def CoreMessage(self, id, bc):
        if id == PLUGIN_ID_COREMESSAGE:
            # Here I also tried storing the dialog in a member variable to make sure
            # there's no conflict/race condition with the dialog closing and dialog
            # object being disposed. No effect on the issue, though.
            OpenModalRequester()

        return True


# Even though I have no idea why,
# it seems, having this popup dialog in the mix (compared to SpecialEvent() from DialogMain),
# massively increases the chance of the issue occurring.
class DialogPopup(c4d.gui.GeDialog):

    def CreateLayout(self):
        if self.GroupBegin(0, c4d.BFH_SCALEFIT | c4d.BFV_SCALEFIT, initw=200, cols=1):
            self.GroupBorderSpace(5, 5, 5, 5)
            self.GroupBorderNoTitle(c4d.BORDER_ROUND)

            self.AddButton(ID_BUTTON, c4d.BFH_LEFT, initw=0, name='Press Me')

        self.GroupEnd()

        return True


    def Message(self, msg, result):
        if msg.GetId() == 1649165891: # if lost focus
            self.Close()

        return c4d.gui.GeDialog.Message(self, msg, result)


    def Command(self, id, msg):
        c4d.SpecialEventAdd(PLUGIN_ID_COREMESSAGE)

        self.Close()

        return True


class DialogMain(c4d.gui.GeDialog):
    _dlgPopup = None


    def CreateLayout(self):
        self.SetTitle('Test Main Dialog')

        self.AddButton(ID_BUTTON, c4d.BFH_LEFT, initw=0, name='Open Popup')

        self.AddDlgGroup(c4d.DLG_OK)

        return True


    def CommandOpenPopUp(self):
        self._dlgPopup = DialogPopup()

        # Being unsure, which plugin ID to pass to subdialogs, I tried PLUGIN_ID as well as a unique PLUGIN_ID_POPUP.
        # Unfortunately without any effect on the actual issue.
        # Assumption is, for modal or temporary dialogs plugin IDs won't matter much and are only used to store and retrieve size info.
        self._dlgPopup.Open(dlgtype=c4d.DLG_TYPE_ASYNC_POPUPEDIT, pluginid=0, xpos=-1, ypos=-1, defaultw=0, defaulth=0, subid=0)


    def Command(self, id, msg):
        if id == ID_BUTTON:
            self.CommandOpenPopUp()

        elif id == c4d.DLG_OK:
            self.Close()

        return True


class CommandDataTest(c4d.plugins.CommandData):
    _dlgMain = None


    def Execute(self, doc):
        if self._dlgMain is None:
            self._dlgMain = DialogMain()

        self._dlgMain.Open(c4d.DLG_TYPE_ASYNC, PLUGIN_ID, xpos=-1, ypos=-1, defaultw=300, defaulth=0)

        return True


if __name__ == '__main__':
    c4d.plugins.RegisterCommandPlugin(PLUGIN_ID, 'Test Dlg From MsgData CoreMsg', 0, None, '', CommandDataTest())
    c4d.plugins.RegisterMessagePlugin(PLUGIN_ID_MSGDATA, str='Test MessageData', info=0, dat=MessageDataTest())

And above code as file:
TestDialogFromMessageData.pyp

Edit: Fixed last minute change of code. Sorry!