Descriptions Vs. AddItem: Getting Mixed Messages



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

    On 02/03/2012 at 09:36, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:   12 
    Platform:   Windows  ;   
    Language(s) :     C++  ;

    ---------
    I'm getting mixed messages about which method to use:
    Descriptions(.res)
    or
    AddItem (cpp)

    Here in these forums. Everybody(including Maxon employees) always, always, ALWAYS, say to use Descriptions.
    However. Recently I've been having a LOT of trouble trying dynamically change dialog plugins with that method. I just can't get them to work at all.
    For Tag & Object plugins. Descriptions work very well. But for dialogs I just can't get them to work.

    Today I discovered the power of the c4d_gui.h file.
    And with the help of the AsyncTest sdk example. I can now do all kinds of cool dynamic changes to my dialogs.
    But...... These have to be done in the .cpp file. Not with external descriptions(AFAIK).

    So I'm confused.
    Here in the forums. Using AddItem in the .cpp files is considered bad practice and we should always use descriptions instead. Even on dialogs.
    However..When it comes to changing dialogs dynamically. I don't see any way to use descriptions to change them. It doesn't even seem possible.

    I've been trying to stick with descriptions (even with dialogs) as recommended. But it looks like I can't use them when it comes to dynamically changing dialog plugins. And I have no choice but to use the AddItem method.
    Please clarify.

    Thanks,
    -ScottA



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

    On 02/03/2012 at 11:42, xxxxxxxx wrote:

    Well now you're confusing me, because I always understood that descriptions were intended for the various managers - the AM, material manager, etc. And that you can't use description elements for dialogs, or use dialog elements in descriptions.

    I treat these two things as entirely separate. I just wonder though - are we talking about the same thing? By 'description' do you actually mean external resource files (extension .res)? Both dialogs and descriptions can have such files, in fact for descriptions these are almost mandatory because it's difficult to create them in code. For dialogs, you can do either and given the nature of the resource editor it's almost easier to do them in code.

    I think there may be some confusion of terms.



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

    On 02/03/2012 at 12:32, xxxxxxxx wrote:

    It was my impression that when you use code in an external .res file to layout your GUI(Regardless of whether it's a dialog or an AM type GUI). That was termed a "description".
    Is this not correct?
    Since .res items have ID's(Long type). I thought that made them descriptions. Just like the descriptions the .h files?

    I'm mostly having problems using these external .res files to control dynamic actions on dialogs.
    If I don't need the dialog to change. Using the external .res method works fine.
    But if I need my dialog to change as the user interacts with it. I cannot figure out how to do that using the .res method.

    Here's an example.
    The code here should make a texbox hide if the second entry of a combobutton is selected by the user:

    Bool myDialog::GetDDescription(GeListNode *node, Description *description,DESCFLAGS_DESC &flags)  
    {  
      BaseContainer *data, *bc;  
      const DescID *singleid;  
      
      if(!description->LoadDescription(node->GetType()))  //Error handling in case loading the resources(.res) fails  
          return FALSE;  
      
      data = ((BaseList2D* )node)->GetDataInstance(); //The container that holds all of the .res items  
      singleid = description->GetSingleDescID();    // <---- undocumented function call  
      
      
      DescID textboxId;  
      textboxId = DescLevel(MY_TEXT_FIELD, DTYPE_LONG, 0);  
      if(!singleid || textboxId.IsPartOf(*singleid, NULL))  
      {  
          bc = description->GetParameterI(textboxId, NULL);   //Assign the textbox to this DescID variable  
          if(data->GetLong(MY_COMBOBUTTON) == SECOND_CHILD)   // If MultiButton is set to setting "TWO"  
              bc->SetBool(DESC_HIDE, TRUE);                   //Hide the textbox  
          else  
              bc->SetBool(DESC_HIDE, FALSE);          //Otherwise...Don't hide the textbox  
      }  
      
      return myDialog::GetDDescription(node, description, flags);  
    } 
    

    This does not work. No errors...I just does nothing.
    However. If I use this same code on a tag or object type of plugin. This code works just fine.

    But if I use the AddItem() method instead. And hide a GUI item like this: HideElement(1001, TRUE);
    It seems to work(Although I'm still getting very flaky results sometimes).
    I would much rather keep using the .res method for my dialogs. But I can't figure out how to make the GUI change dynamically with that method.

    -ScottA



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

    On 03/03/2012 at 02:54, xxxxxxxx wrote:

    I'm not surprised it doesn't work. GetDDescription is only available in classes ultimately derived from BaseData, which GeDialog is not. C4D will never call the overridden function so it will have no effect. It will only work in tags, tool plugins, shaders, etc.

    If you want to change your dialog dynamically you need to look at using layout functions like LayoutFlushGroup to remove existing elements from a group and the various Add functions to add the new elements back in. You can use a .res file to get the initial dialog layout then change the layout depending on what the user does.

    You cannot use those dialog layout functions for anything other than dialogs. To avoid confusion I think it's best to consider the two things - dialogs and everything else - as two completely separate systems that just happen to share things like element names. Don't try to use dialog functions in the other type of interface and don't use the other interface functions in dialogs.



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

    On 03/03/2012 at 08:26, xxxxxxxx wrote:

    Originally posted by xxxxxxxx

    If you want to change your dialog dynamically you need to look at using layout functions like LayoutFlushGroup to remove existing elements from a group and the various Add functions to add the new elements back in. You can use a .res file to get the initial dialog layout then change the layout depending on what the user does.

    That's what I was trying to get someone at Maxon to confirm.
    Based on my experiments. And your findings too. When it comes to making dynamic dialogs(GUI items animate). We can't just use descriptions. That's not going to cut it.

    As far as I can see. This is how it seems to work:

    • Dialogs : We MUST use the Add functions to create a dynamic dialog. Descriptions can also be used. But only for static dialog elements that will not change during user interactions.

    • All other plugin types : Descriptions will work for both static & dynamically changing GUI items in the AM. There is no need to use the Add functions with these types of plugins.

    If this is accurate information. Then it needs to be added to the docs to avoid confusion.

    -ScottA



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

    On 04/03/2012 at 06:01, xxxxxxxx wrote:

    Descriptions are only used for 'objects' which display information in the Attributes Manager.
    Dialogs have their own elements which are different.
    One of the only areas of overlap is a Tool plugin with a SubDialog shown in the Attributes Manager.

    Resource files can be used for either descriptions or dialogs but they should be looked at as two separate types of resources.  You can't really mix them together even if some of the elements between are syntactically similar.



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

    On 04/03/2012 at 08:28, xxxxxxxx wrote:

    Ok. Thanks Robert.

    I think what I'm going to do to make it much more clear is to never use a .res file with any of my dialogs from now on. Even though I can use them for static elements if I wanted.
    It's not that much of an inconvenience to me to put them in the .cpp files. And I rarely need to edit them. So the need to re-compile when they are changed isn't really an issue for me. And not worth the hassel of getting them confused with my AM resources.

    The only thing that I can see maybe becoming an issue with this work flow is if I want to use a customGUI type dialog down the road.
    Since I haven't really gotten into those yet. And don't know what's involved. I don't know if I'll be forced to use .res files for them.

    -ScottA



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

    On 08/03/2012 at 00:10, xxxxxxxx wrote:

    I'd like to add another view on descriptions, as I was confused by descriptions and resource files as well.
    By now, I figured, a description is called description, because it describes a data object. And to ease the use within attribute managers these descriptions contain not only type information, but information about GUI elements as well. Furthermore, resource files can be used to describe GUI elements and implicitly generating these descriptions, but I think, the resource file itself is just a very nice helper here.
    Dialogs on the other hand have nothing to do with data types in the first place. They are GUI plain elements.
    I played around with dialogs, using static resource files in combination with dynamically generated GUI elements and CustomGUI elements in my ColourTable plugin. Source can be viewed and retrieved here: http://code.google.com/p/colourtable/source/browse/#svn%2Ftrunk%2Fsource


Log in to reply