ID locations - 3 options which best
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 02:05, xxxxxxxx wrote:
I've opened up 3 Python plugins and the enum ID are in 3 different files
Can someone tell me where the should be
I've seen them in
res/symbols.h (I've been told this isn't used by python - but its from a working plugin so ??)
res/description/PLUGIN_NAME.h
and at the top of the .pyp file
from a newbie POV to plugins this is really disconcerting
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 02:24, xxxxxxxx wrote:
The best and recommended place for the enum ID is in the description's header file. In Python you can then access the IDs in c4d namespace.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 02:37, xxxxxxxx wrote:
Just what I needed to know - thanks Yannick
so to confirm - that is...
res/description/PLUGIN_NAME.h -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 08:09, xxxxxxxx wrote:
^Correct.
This can be a very confusing subject to people that have never used OOP file structures before.
"symbols.h" found in the "res" folder is not the same file as the description.h file found in the "description" folder.
symbols.h is not used in python plugins. But it is used with Coffee & C++ plugins.
So the place you want to put the ID's is the .h file that sits next to your .res file. inside of the description folder.Now before you get all comfy with that and try to memorize it. Wait...
There will be times when you make a plugin that does not have a description.h file.
In that case. You could put your ID's at the top of your .pyp file.
*Just understand that these are then global variables that way. And while they work just fine in C4D plugins. Globals are generally considered bad practice in coding.
But you'll see lots of plugins supplied by Maxon and other people using globals in them. I use them myself from time to time when I feel lazy. They are not going to burn your house down.
So don't freak out about it. It's really the easiest option in some cases.
Just understand that you don't want to use them that way outside of C4D programming.Think we're done yet? nope.
What happens if you want to create a resource based dialog plugin with Python?
There is no "description" folder in a plugin like that...Now what?
Instead. There is a "dialogs" folder. And inside of that folder is where you put the .res and .h files.Sorry if this seems like a complicated answer to your simple question. But frankly. It is a rather complex thing to wrap your head around when you've never done it before.
This object oriented programming stuff, where files are spread out all over the place, can be very confusing.The big point I'm trying to make is. Don't memorize any one way of doing things. Because it changes depending on what you're doing. There's no single one way that covers every situation.
-ScottA
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 09:29, xxxxxxxx wrote:
Brilliant
This is the sort of info us newbies need.
ta Scott
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 10:06, xxxxxxxx wrote:
I'll add an explanation like this in the documentation because it seems there's lot of confusion when developing plugins with descriptions, dialogs, enum IDs, string tables etc.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/04/2012 at 12:00, xxxxxxxx wrote:
It may not be what you want, but, if I get this JSPline plugin off the ground I'd be happy to donate some of my thoughts as a newcomer to plugins to provide a user perspective to any guide.
The problem with most technical guides, is that they build from scratch. So you don't know if something is put in because it is always needed - or part of what you are creating.
Taking a generator object and turning it into a plugin is proving interesting and educational. Having the original object really highlights the extra parts required for (this example of) plugin creation.
If Scott and Lennart were OK with it (they supplied the initial plugin base code I'm using).
I'd be happy to see the JSpline Python Generator to plugin conversion split into parts to illustrate the process for a learning resource.