Updating dialog from TreeView

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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:

BaseContainer msg;  
msg.SetId(BFM_LAYOUT_CHANGED);  
SendParentMesssage(msg);

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...

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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!
Best
Katachi

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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:

#include "MyDialog.h"  
  
class MyTVF : public TreeViewFunctions  
{  
     private:  
          MyDialog*     dialog;  
     public:  
          InitMyTVF(MyDialog* t_dialog)  
          {  
               dialog = t_dialog;  
          }  
          ...  
          void Select(void* root, void* userdata, void* obj, LONG mode)  
          {  
               ((TreeRoot* )root)->SetSelected((TreeItem* )obj, mode);  
               dialog->SetSelected((TreeItem* )obj);  
          }  
          ...  
} functable;  
  
...  
  
void MyDialog::SetSelected(TreeItem* titem)  
{  
     SetBool(GID_CHECK, titem->GetFlag());  
}

I would call 'InitMyTVF()' in the same place where you set the root for the tree CustomGUI.

Let me know if that makes sense.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

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.

Thx
Best
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/08/2006 at 12:15, xxxxxxxx wrote:

Hello Samir,

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.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/08/2006 at 12:19, xxxxxxxx wrote:

cool, thx for rechecking!