On Mon, 2010-09-13 at 09:26 -0700, Martin Poirier wrote: > Hi, > > I talked with Campbell about that problem yesterday, actually. > > I think the issue is that you're bypassing the metaclass by constructing the > class through a call to type(). > > We couldn't see any reason why you couldn't use the normal class syntax > instead. The name of the class doesn't matter when registering, so you can > just do something like this: > > for ...: > class MyOperator(bpy....): > poll = PollClassMethod > ... Hi Martin, I tried this: http://pastebin.com/3j2HG5Yy and I still get: invalid operator call OBJECT_OT_copy_OBJ_LOC
on the console when trying to actually call the operators... something is still not right, any clues? cheers Bassam > > > I can check that this week if there are still issues. > > Martin > > > --- On Mon, 9/13/10, Bassam Kurdali <bkurd...@freefactory.org> wrote: > > > From: Bassam Kurdali <bkurd...@freefactory.org> > > Subject: [Bf-committers] registering 'dynamically generated' ops? > > To: bf-committers@blender.org > > Received: Monday, September 13, 2010, 11:38 AM > > Hi all > > Since Martin's commit for I believe metaclassing, > > registering ops > > became obsolete, raising an AttributeError, instead, ops > > created (via > > python) are automatically registered- very nice! > > However I have one script (the clone of 2.4x's copy > > menu): > > https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/space_view3d_copy_attributes.py > > > > This script dynamically builds the ops, so that it is easy > > to extend > > just by writing a function that copies something from one > > object (or > > bone) to another, the rest (looping over all the selected > > bones, making > > the operators to be called from the menu) is handled more > > or less > > automatically by the script. > > > > Before Martin's commit, I had a small loop in the register > > function > > that would go over the list of generated ops and register > > them one by > > one. After the commit, this raised an attribute error as > > expected. So I > > removed the registration of the ops, and the script runs > > without error, > > However, when I try to execute any operator from the menu, > > I get an > > error on the console, indicating that my operator call is > > invalid - it > > seems I need to register those operators explicitly after > > all. > > > > I found a workaround that worked for me, this was making a > > loop to > > unregister all the dynamically generated ops, and then to > > register them > > again. This works fine on Linux, but the unregistering step > > failed on > > meta-androtico's Windows 7 machine! so finally I have > > wrapped things in > > a try - except, where: > > first we try to just register the ops (shouldn't be needed > > but is) - > > this works on windows 7, > > second if we get an AttributeError exception, we unregister > > the ops, and > > then register them again ( this works on Linux ) > > > > Clearly this is not ideal, I think we should find a better > > way, so my > > question is: > > Am I doing something wrong? is there a 'right way' to do > > this for > > dynamically generated operators? and finally, why is the > > behavior OS > > dependent? > > > > Cheers > > Bassam > > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers