Interesting idea. The property is created via an object model method:
oProp = activesceneroot.addproperty()
Then the property is inspected in siModal mode. Whether the user
clicks cancels or OK, the property is deleted:
oInspect = inspectobj( oProp, '', 'prop', siModal, False )
if not oInspect:
# record property parameter values here
deleteobj( oProp )
return (...)
else:
deleteobj( oProp )
return None
I have not tested if the user clicks the X button on the top right,
but will asap. The problem occurs both in fresh new scene with as with
scenes where the commands have already run. I'll keep an eye on those.
Thanks for the suggestion.
Bernard
On 8/31/05, Andrew Skowronski <askowron(at)softimage.com> wrote:
> Are there old copies of the custom property that you use to ask the user the questions being left around in the scene? Maybe you normally delete the custom property but in some scenario (cancelling?) it leaves it in the scene and although a new one is created when the user tries again, it is the original that is read by your command?
>
> -Andrew
>
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]On Behalf
> Of Bernard Lebel
> Posted At: Wednesday, August 31, 2005 4:11 PM
> Posted To: xsi
> Conversation: [script] Same python code, different results
> Subject: Re: [script] Same python code, different results
>
>
> A quick update on this old thread...
>
> Remember that I'm having troubles with a self-installed command that
> calls other self-installed commands. When the first one is called, the
> user is prompted with a modal ppg, where he has to enter some
> parameters. On of these infos is the shot number (along with episode
> and sequence).
>
> To help myself trouble shooting these scripts when a problem occurs,
> these commands print lots of messages. Among these message, the
> information relating to the shot number is printed. So technically,
> you would expect these command to print the same shot number infos
> than those entered by the user, right?
>
> Well I have noticed that sometimes, for some obscure reasons, the shot
> number processed by the secondary commands is not the same than the
> one entered by the user. Specifically, the shot number processed by
> the command is an old shot number, that the user previously worked on.
>
> I could notice that because the problem happened to me a few times.
> Since I do very little shots compared to the other artists, when I
> noticed that, I saw a shot number that I had worked few days ago. It's
> not the first time it happens to me.
>
> I have yet to find an explanation for this, as the commands do not
> store any information on disk, do not do pickling, or anything that *I
> thing* should cause some persistance of such data. Unless there is
> some bug or caching mechanism that we poor motal users don't know
> about? Perhaps there is a brute force way flush any reference to data
> that could be used after the commands complete their task?
>
> Then the second or sometimes the third time I run the commands, it
> works without a problem. As I said in the beginning of this thread,
> sometimes one needs to restart XSI, sometimes it just works the next
> time the user runs the command.
>
>
> One last comment: since I originally posted about these problems, it
> seems things improved without any intervention from my part. I don't
> know why, but users stopped reporting these problems not long after. I
> doubt it still happens but they don't tell me, because these shots
> would bounce back to them sooner or later, wich is not the case.
> Perhaps it is my karma then :-)
> (I hope so)
>
>
> Cheers
> Bernard
>
>
> On 8/15/05, kim aldis <kim(at)cg-soup.com> wrote:
> > My thoughts were more along the lines of code left inadvertantly in other
> > workgroups, or my classic, making a backup suddirectory of my plugins
> > folder, not realising that xsi uses the directory recursively and spending
> > an hour or so trying to find out why my plugins were failing to load, still
> > working but working incorrectly.
> >
> > The idea of using logged versioning to prevent this from happening isn't a
> > bad one, though.
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-xsi(at)Softimage.COM
> > > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Andrew Skowronski
> > > Sent: 15 August 2005 19:49
> > > To: XSI(at)Softimage.COM
> > > Subject: RE: [script] Same python code, different results
> > >
> > > Having some out-of-date script files in memory is a good
> > > theory - XSI caches a self-installed plug-in script in memory
> > > once it is first instantiated.
> > >
> > > So in Kim's scenario the Logmessage won't actually show up until
> > >
> > > -XSI restarted
> > > -Update button on Plug-in Manager pressed -Some OM code
> > > called to unload/reload the specific plugins
> > >
> > > -Andrew
> > >
> > > -----Original Message-----
> > > From: owner-xsi(at)Softimage.COM
> > > [mailto:owner-xsi(at)Softimage.COM]On Behalf Of kim aldis Posted
> > > At: Monday, August 15, 2005 12:17 PM Posted To: xsi
> > > Conversation: [script] Same python code, different results
> > > Subject: RE: [script] Same python code, different results
> > >
> > >
> > > try taking the plugins you think everyone is using, add a
> > > coded logmessage in the init or command, wait for a baddy and
> > > see if the log is there, or check see if everyone gets the log.
> > >
> > > > -----Original Message-----
> > > > From: owner-xsi(at)Softimage.COM
> > > > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Bernard Lebel
> > > > Sent: 15 August 2005 17:08
> > > > To: XSI(at)Softimage.COM
> > > > Subject: Re: [script] Same python code, different results
> > > >
> > > > Here the issues affects self-installed commands, not imported
> > > > libraries. Isn't the command names garbaged collected immediately
> > > > after it returns?
> > > >
> > > > Bernard
> > > >
> > > >
> > > > On 8/15/05, xsibrad(at)fie.us <xsibrad(at)fie.us> wrote:
> > > > > I have been noticing some oddities on our python setup as well...
> > > > > though nothing as large as what you seem to be running into.
> > > > >
> > > > > Since I never removed the LogMessage commands from some
> > > of our self
> > > > > installed python commands (ir lazy), I do get to see when
> > > they init
> > > > > and all that jazz (hey, we're still in developoment... not
> > > > release).
> > > > > and often a python self installed command will fail to init
> > > > once and then init fine the next time...
> > > > > with no changes to its code. So far it has not caused any
> > > > major problems.
> > > > > Except of course the problem of confusing and belittling
> > > > the programmer (me).
> > > > >
> > > > > I guess the next obvious question is: has this been
> > > > happening during a
> > > > > period that you've been coding into your python tools? Is
> > > > it possible
> > > > > that a module has been loaded into the python runtime for
> > > > like... two
> > > > > days... since some artists may leave XSI running that long?
> > > > In that
> > > > > time, you could have updated the code twice... but they
> > > > might still have the old version loaded into memory.
> > > > > Or is that a wild goose chase too? I thought I'd point out the
> > > > > obvious easy solutions first. Cause the next suggestion becomes
> > > > > testing out different python installs (activestate vs.
> > > > python.org etc). ouch.
> > > > >
> > > > > -brad
> > > > >
> > > > > Quoting Bernard Lebel <3dbernard(at)gmail.com>:
> > > > >
> > > > > > Andrew:
> > > > > >
> > > > > > >> Maybe there is a command conflict (same command name
> > > > > >
> > > > > > I'm pretty sure that is not the case! I mean,
> > > otherwise, wouldn't
> > > > > > all of the 25 users of the workgroup run into these
> > > > problems? I seem
> > > > > > to never run into these problems (or almost), while some
> > > > others run
> > > > > > into this several times a day.
> > > > > >
> > > > > > >> or command scripting name being used more than once)?
> > > > > >
> > > > > > Hum I will 100ple-check that, thanks for the tip.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kim:
> > > > > >
> > > > > > > Sounds to me like some of the machines are looking at older
> > > > > > > versions of code?
> > > > > >
> > > > > > That is extremely unlikely. The reason is the only plugin the
> > > > > > Plugins directory in the workgroup contains is a plugin
> > > > loader, it
> > > > > > explicitely load plugin files that are located in a
> > > directory not
> > > > > > part of the workgroup. Unless the plugin loader has duplicate
> > > > > > entries, loading plugins of the same name twice is
> > > > technically impossible.
> > > > > >
> > > > > > But again I will 101ple-check all this stuff. Thanks
> > > for the tip.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Bernard
> > > > > >
> > > > > > ---
> > > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > > > following text in body:
> > > > > > unsubscribe xsi
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > This message was sent using IMP, the Internet Messaging Program.
> > > > >
> > > > > ---
> > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > > > following text in body:
> > > > > unsubscribe xsi
> > > > >
> > > >
> > > > ---
> > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > > following text in
> > > > body:
> > > > unsubscribe xsi
> > > >
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> > > text in body:
> > > unsubscribe xsi
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> > > text in body:
> > > unsubscribe xsi
> > >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > unsubscribe xsi
> >
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
