On Friday 08 November 2002 07:42, Kaleb Pederson wrote: On Thursday 07 November 2002 10:14 pm, Boudewijn Rempt wrote:
> <snip> > > Hmmm... What I do is to create a Python class with the settings as member > variables. That makes it easier. But still, the Qt documentation says: > > A typical usage pattern for application exit or 'save preferences': > > QSettings settings; > settings.insertSearchPath( QSettings::Windows, "/MyCompany" ); > // No search path needed for Unix; see notes further on. > settings.writeEntry( "/MyApplication/background color", bgColor ); > settings.writeEntry( "/MyApplication/geometry/width", width ); > // ... > > So, depending on the destructor is not the only way to go. I agree that it shouldn't be the only way to go. I would definitely prefer to have a function that I can call that would write to disk. The source code reveals, however, that a sync() call is only done in the destructor. In fact, I have almost exactly what you mentioned. I have a class that wraps it and provides some convenience functions for me. I added in some print statements so I *know* that settings.write[Num]Entry is getting called with all the correct values. I guess my main question is, therefore, if I have a reference to a PyQt object, in this case QSettings, and at the close of my program the destructor never gets called for the PyQt object, then there _must_ be a memory leak if any memory whatsoever is allocated by that PyQt object. Is there a way that I can purposefully circumvent the destructor of a PyQt object? In my application, I simply let the module level global go out of scope assuming that the destructor would get called; it never does. Under *nix, has anyone ever seen QSettings actually write to the settings file upon a write[Num]Entry? I have monitored the file for existence upon a new write[Num]Entry and for changes upon a write[Num]Entry and None have ever been made until the object goes out of scope. --Kaleb _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
