THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/08/2006 at 14:11, xxxxxxxx wrote:
Cinema 4D Version: 9.6
Platform: Windows ;
Language(s) : C++ ;
I would like to update my dialog when I select an item in my treeview. Ok, I can easily trigger the selection event in the treeview but I see no call or message I could send to update the other dialog elements.
Is there a way to force a complete refresh of the dialog?
On 18/08/2006 at 15:47, xxxxxxxx wrote:
Where GROUP is the group ID and CreateMyGroup() is a method that works like CreateLayout(). This is mainly used when you need to update GUI elements that can't simply be set using their Set...() type methods. For instance, to change a Checkbox, you can instead just call SetBool(ID, val). But for group changes or more major changes, you need to go the aforementioned route.
On 19/08/2006 at 01:25, xxxxxxxx wrote:
hmm, thanks Kuro but that doesn´t look like a straightforward way. I don´t wanna rebuild the group just to update it as I´d do for dynamic layouts. I am looking for a way to simply refresh the whole dialog with all its elements in it. There must be a message for this as I doubt Cinema 4D rebuilds all managers everytime there is a change. At least I hope.
On 19/08/2006 at 05:34, xxxxxxxx wrote:
As far as I am aware, that is the only way. There is no GUI message that allows a group update - and there are definitely no methods in the SDK for changing a dialog group (I've looked very hard myself for the same reasons).
There are some GUI messages involved in layout changes, but not much is said of them. What is it that specifically need to update?
On 19/08/2006 at 05:44, xxxxxxxx wrote:
When I remove an item from my treeview the whole dialog gets updated, but not for selection states, so there must be a message forcing the dialog to update its elements (whether it is documented or not). Doesn´t have to be specifically a message, could be a direct call. I don´t know how it knows it shall update, but that´s why I am asking here.
And the one who implemented the treeview customgui should be well aware of how to do that. I assume it´s a parent message to the dialog it´s attached to, but I´d like to know which one.
There is nothing special that needs to update, it´s the whole dialog (resp. all elements in it) that need to be updated as currently they don´t. But a rebuilt seems like a hack to me rather than a valid way. (sure, if there really isn´t a message accessible, then I have to go that way, but I would like to keep it straightforward instead of using workarounds).
On 19/08/2006 at 08:34, xxxxxxxx wrote:
It really isn't a work around - this is the exemplified way - see AsyncTest.cpp.
On the other hand, there is one message here using this after adding GUI elements:
Maybe the same could be done for the update?
But, I know how you feel. I've been wanting to allow keyboard traversal in a treeview, but have no idea how to do it since the GeUserArea is held by the treeview itself, keys don't seem to work (they might be gobbled up by the GeUserArea before they reach the dialog which is the only place to react to them).
Hopefully one of those who understand have answers...
On 19/08/2006 at 09:38, xxxxxxxx wrote:
yeah, that´s the exemplified way for *dynamic* layouts as in AsyncTest.cpp. look at when Relayout is called, only when the user adds or substracts rows. But that´s not a refresh solution.
You know, I could save all the hassle and simply use it, but I like to create reusable code and well, you know, that´s far from being reusable But I guess you know that.
I already tried directly calling LayoutChanged() for the dialog pointer but that instantly crashed my c4d. Same for sending that parentmessage you suggested.
ANYWAY, I now simply send an own message with SpecialEventAdd() and catch it in CoreMessage. That´s not the most elegant way, as I still think a simple Refresh() method for a dialog should be implemented, but it works without problems.
Thanks for your help though Kuro!
On 19/08/2006 at 11:29, xxxxxxxx wrote:
Right. In my situation, one group is a dynamic layout (tied to the treeview selection).
Glad that your less elegant way works.
When you say that you are updating the entire dialog with elements in it, to what extent. If the groups aren't changing, only the elements, one would think that you could get away with the Set...() methods to update elements. You can even change group titles with SetString() - this should work for statictext as well. I have read that RemoveElements() doesn't update the dialog, but if you are not adding/removing elements this should be of no concern.
For instance, I've recently added a Search feature group that has a treeview (mainly for columns) which is filled with results and cleared without dynamic stuff. Of couse, the treeview has a Refresh() method.
The group also contains a static text that is used for information (searching..., how many items matched). It starts off as an empty string (String("")), but a simple SetString(text) suffices to update.
Basically, there are several levels of 'update' for a dialog or its elements. Adding/removing usually requires the dynamic route. Changing dialog elements should only require Set-ting or specific refreshes for customguis. Resizing, reorganizing elements might be trickier if this is your intention.
On 20/08/2006 at 23:31, xxxxxxxx wrote:
that was the problem. Using the Set() methods from within the treeview didn´t update the dialog! That´s why I needed to move it to one of the dialog functions, but also a way to tell the dialog that it should update.
On 21/08/2006 at 06:58, xxxxxxxx wrote:
Ah, that's more explanatory.
So, I take it you want dialog updates caused by things that are happening in the TreeViewFunctions (and possibly your tree item clases)?
You can store a pointer to the dialog (as a class member of your TVF class). Just pass it to the TVF using your own public InitTVG() method or something. Then you can call methods of the dialog to do the settings in the TVF methods.
On 21/08/2006 at 08:07, xxxxxxxx wrote:
I should like to add that after rereading your initial post, I may have been thinking to much about this and not seeing the exact situation.
There should be no problem having Set...() methods called within the dialog udpate the dialog - I do this all the time without any messaging required. To paraphrase the idea:
class MyTVF : public TreeViewFunctions
dialog = t_dialog;
void Select(void* root, void* userdata, void* obj, LONG mode)
((TreeRoot* )root)->SetSelected((TreeItem* )obj, mode);
void MyDialog::SetSelected(TreeItem* titem)
I would call 'InitMyTVF()' in the same place where you set the root for the tree CustomGUI.
Let me know if that makes sense.
On 25/08/2006 at 09:03, xxxxxxxx wrote:
Hey Kuro, sorry for the long delay, my i-net connection screwed up for about a week (I hate my provider btw.).
And hey, darn me, I directly called the Set() methods from within my treeview (so I got that pointer in my TVF already but I did sth like dlg->SetString() in the TVF!) and that didn´t work, but I was too narrow-minded to try it with a simple call to an implemented dialog method of my own.
I am not sure if that works (but I assume you tried it and it did?) but I will definetly keep this in mind next time I can´t see the woods.
On 25/08/2006 at 12:15, xxxxxxxx wrote:
I know about connection problems.
I've tried it and it does work. In my case, the call goes to the class specified as the root (where the dialog pointer is stored as well) and then onto the dialog call. I just did a simple test that uses SetString() in a similar manner as exemplified in my previous message to change a static text dialog item to the tree's selected item's text.
On 25/08/2006 at 12:19, xxxxxxxx wrote:
cool, thx for rechecking!