Detect closing of Document

lasselauch

I basically want to react in my GeDialog if my active document has been closed.
I'm currently looking at MSG_DOCUMENTINFO but there's no flag for a closed document... one other idea would be to listen to a CallCommand for example via c4d.MSG_DESCRIPTION_COMMAND?

What would be the best way to approach this..?

Thanks,
Lasse

mp5gosu

Hi Lasse,

MSG_DOCUMENTINFO provides MSG_DOCUMENTINFO_TYPE_REMOVE and MSG_DOCUMENTINFO_TYPE_SETACTIVE.

Yo you could do a simple compare when a new active doc is set, if your desired document still exists.

ferdinand

Hi @lasselauch,

thank you for reaching out to us. @mp5gosu provided to some degree the correct answer (thanks for that). However, you should consider that not all message types are being sent to all Message methods. In the c4dpythonic way of looking at Cinema's public API, MSG_DOCUMENTINFO is part of the MSG PLUGINS channel which is only being broadcasted to plugin nodes. So you won't be able to receive it in a dialog's Message or CoreMessage method.

The easiest way would be to use some kind of plugin node for that. I currently do not see a way to do this in a GeDialog, but I might be wrong. We will discuss that tomorrow in the SDK Team, to see if the others know a clever way to do that. Just wanted to make sure that you do not run down a rabbit hole with no exit

Cheers,
Ferdinand

lasselauch

Thanks, @mp5gosu ...!

@zipit said in Detect closing of Document:

The easiest way would be to use some kind of plugin node for that. I currently do not see a way to do this in a GeDialog, but I might be wrong. We will discuss that tomorrow in the SDK Team, to see if the others know a clever way to do that. Just wanted to make sure that you do not run down a rabbit hole with no exit

Hehe, yeah that's exactly what I thought when looking at MSG_DOCUMENTINFO . Thanks for the quick answer, Ferdinand. Looking forward to your thoughts and ideas...

Cheers,
Lasse

lasselauch

I guess I found a workaround... I cannot show the whole code involved but something along those lines:

I have a Treeview that stores an absolute path abs_path of different documents... Now, I just check if one of these filepaths is in my open documents paths via: get_all_docs_paths()

def get_all_docs_paths():

    all_docs_paths = []

    first = c4d.documents.GetFirstDocument()
    while first:
        folder = first.GetDocumentPath()
        abs_path = os.path.join(folder, first.GetDocumentName())
        all_docs_paths.append(abs_path)
        first = first.GetNext()
    
    return all_docs_paths

If yes, the document is open, if not it is closed.

Cheers,
Lasse

mp5gosu

By the way, I also ended up multiple times implementing a message plugin for those kind of actions.
MessageData plugins are extremely simple to implement and expand your flexibility a lot!

ferdinand

Hi @lasselauch,

we talked about your problem this morning. There are two ways of looking at your question:

You are interested in the event of a closing document (i.e. present progressive) and you want to react to that event by making some changes before this process is finalized (i.e. the document closed). As already stated yesterday by me, there is currently no way to do that in a GeDialog. You will need some kind of node for that. It is also noteworthy that currently CommandData is bugged in this regard in Python. As @mp5gosu already pointed out, MessageData is a really good way to go, unless you do not have already something like TagData plugin where you could squeeze in that functionality.
You are interested in the state of the loaded documents list, i.e. if a document has closed (past tense), but not exactly when it happens. This is possible in a dialog. You already provided your own answer here (thanks for making it visible to everyone). The basic idea is just to build some hashmap/list to compare against what Cinema considers to be loaded documents. As an added note, you might want to look at GeDialog.Timer, which will let you execute things in fixed intervals, in order to get closer to the point of when something happened. This won't be to much of a performance strain if implemented carefully.

Cheers,
Ferdinand