Trying to simplify things a bit

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

On 26/02/2011 at 09:12, xxxxxxxx wrote:

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

---------
Hey guys,

This is probably going to sound like a strange thing to ask.
But I was wondering if there was a way to write the dialog resources stuff inside of the same .cpp file that contains the other code?

I'd like put them in the .cpp file so when I'm testing things out. I can quickly glance at them and change them. It's easier for me this way than having them in separate folders.

Here's an example of the kind of resources I'm talking about:

CONTAINER Tlookatcameraexp  
{  
 NAME Tlookatcameraexp;  
 INCLUDE Texpression;  
  
 GROUP ID_TAGPROPERTIES  
 {  
     BOOL LOOKATCAMERAEXP_PITCH { }  
 }  
}

Thanks,
-ScottA

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

On 26/02/2011 at 09:31, xxxxxxxx wrote:

Well, you could use the functions "AddButton()", "AddCheckbox()" and so on. :smile:

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

On 26/02/2011 at 11:09, xxxxxxxx wrote:

I was kind of hoping that I could use the other type of code. That way I could cut and paste it into a res->description folder when I'm done setting things up.

I also don't know how to use those Add() functions with C++. I've only used them to create dialog windows in Coffee. And I don't want to create dialogs.
I want to add attributes to objects and tags. So I don't even know if they will work for that.

I give it a try. But I'm failing miserably:

class BasicObject : public ObjectData  
{  
    
  public:          
      virtual Bool CreateLayout(void);  
      etc...  
      etc...  
};  
  
  
Bool BasicObject::CreateLayout(void);  
{  
 C4DGadget *AddStaticText(LONG id = 1, LONG BFH_LEFT, LONG initw = 10, LONG inith = 10, const String& = "MyText", LONG borderstyle = 0);  
  
 return TRUE;  
}

It's telling me that member function BasicObject::CreateLayout(void) can't be redeclared outside it's class.

I've looked around and I can't find any examples of using these add() functions with a C++ project to learn from.

-ScottA

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

On 26/02/2011 at 11:56, xxxxxxxx wrote:

What you mean with "adding elements to objects" ?
Userdata ? Or do you mean the Description for a ObjectData subclass ?

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

On 26/02/2011 at 12:26, xxxxxxxx wrote:

Take a look at the "Look at camera" tag example in the SDK.

Instead of the gizmos being located inside a dialog window that pops up. They are located as children of the tag itself. Sort of like User Data.
The same kind of thing can be done with object plugins.

These descriptions are written with a different type of syntax from the dialog(popup) windows.
And I was hoping that I could place them inside my .cpp file. Instead of them needing to be placed in a separate res->Description folder.

-ScottA

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

On 26/02/2011 at 12:29, xxxxxxxx wrote:

Dialogs are different than objects (documents, objects, tags, etc.).  The latter use Descriptions.  Static descriptions are declared in the .h, .res, and .str files for the object (Omyobject.h, Omyobject.res, Omyobject.str).  These are what you see in the Attributes Manager.  They are not dialog elements.  The only object that does use dialog elements is the Tool type (using a SubDialog which you hook into the ToolData).

Dynamic Descriptions are sort of what you want.  You can add descriptions 'dynamically' in the GetDDescription() method.  Realize that this is not the recommended way for static descriptions as it is slower and costly in execution (the descriptions are rebuild constantly).

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

On 26/02/2011 at 13:23, xxxxxxxx wrote:

Thanks Robert.

I see there's a few examples using GetDDescription() in them.
I'll see if I can figure out how it works.

-ScottA

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

On 01/03/2011 at 03:41, xxxxxxxx wrote:

I'd say it's probably easier to change your description resource files than to add description elements via GetDDescription(). I'd only use GetDDescription if your interface changes dynamically.

cheers,
Matthias

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

On 01/03/2011 at 07:44, xxxxxxxx wrote:

I'm starting to see it that way too Matthias.
It's also kind of nice to be able to change the code in the external files without having to recompile.

The problem is I'm new at this stuff. And right now I'm just using small bits of code at a time. So all of these external files to deal with is way,way, way overkill for what I need.
Plus it's very, very confusing to understand what goes where with everything spread out like this.
But I think I have it all chopped down to the bare essentials now. And have a simplified folder structure template that I can use without thinking about what goes where anymore.

When you guys post code here. Like the xpresso snippets for example. It's not the code that's hard for me to understand. It's how to create the proper external file structure for them that gives me the most trouble.
You guys probably don't even think twice about that stuff anymore. But when you're new like me, those externals can be very confusing.

-ScottA

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

On 01/03/2011 at 09:16, xxxxxxxx wrote:

The file/folder structure isn't too difficult once you understand the structure.

You create a folder in which to place your plugin (everything).  This will directly contain your compiled plugins and any other non-essential files (readme.html, for instance).  This will also contain the 'res' folder.  All of your resources go in here (descriptions, plugin headers, .str, .res, icons, images, possibly even your html help or PDF file).  Basically:

[Cinema 4D RXX]
-->[Plugins]
---->[MyPlugin]
------>myplugin.cdl
------>myplugin.cdl64
------>myplugin.dylib
------>[res]

The res folder has the plugin headers, string files, and resource files and should be where you put your icons, images, and other static resources needed by the plugin.  There are two levels to the resources: one is for general, typically used with Command plugin dialogs, and the other is for other types of plugins (objects, tags, materials, tools, etc).  The first is covered by two files:

c4d_symbols.h
c4d_strings.str

The first enumerates general constant name-value pairs.  This usually includes the name-value pairs for text going into a dialog and possibly dialog ids and plugin ids.

The second str file associates any of the name-value pairs that represent string constants used in your plugins with text.  Note that there can be multiples of these if using more than one language.  Typically you might only have a 'strings_us' folder containing the c4d_strings.str but you may have more if you support other languages.

So, the first level structure is:

...
[res]
-->c4d_strings.str
-->[strings_us]
---->c4d_strings.str
<Optional>
-->[strings_de]
---->c4d_strings.str
-->[strings_jp]
---->c4d_strings.str
...etc

Inside this same structure you put your second level plugin resources.  These are placed into a 'description' folder in both the 'res' folder and each consequential 'strings_xx' folder.  The main description folder contains the header (.h) and the resource (.res).  The one in strings_xx contains the .str file.  For a plugin type Omyplugin, you would have (as well as the first level files) :

...
[res]
-->[description]
---->Omyplugin.h
---->Omyplugin.res
-->[strings_us]
---->[description]
------>Omyplugin.str

C4D is using something of an MVC (Model-View-Controller) design pattern but not sure if that is the exact pattern being used.

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

On 01/03/2011 at 10:13, xxxxxxxx wrote:

Lol..If that's what you call simple. I'd hate to see what you call complicated. :wink:

I do have a cheat sheet I've set up for myself with basically that information Robert. But it's going to be confusing to me for a while until I use a few dozen times or so.

As a newbie. I find myself wishing there was a "training mode". Where the externals could be put into the same file as the code.
Or maybe even just one single external file. Where the new user could cut their teeth first, before advancing to using multiple files and folders.

-ScottA

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

On 01/03/2011 at 17:38, xxxxxxxx wrote:

Lmao! :blush:

Well, it is only three general parts.  The Beelzebub is in the details.  Yeah, this setup makes it difficult to track each item.  I typically add a set of controls in the header and then fit them into the resource and then add their strings into the string file.  As you noted, these files don't require rebuilds so you can get the text right (.str) and the layout right (.res) just by editing these files and checking the results.

For dialogs, there is ResEdit (sic) which gives a graphic interface for designing dialogs.  Wish there was something similar for Descriptions.  (Lightbulbs going off!) :)