[Kde-perl] Why isn't this easy? implementing File->New

darrik darrik at mythofbutterfly.com
Wed Aug 2 02:40:28 CEST 2006


Joe Carlson wrote:
> On Tue, 2006-08-01 at 19:35 -0400, darrik wrote:
>> I've found this works, and I'm thinking it has to do with variables 
>> going out of scope, automagic destructors, and perl garbage collecting.
>>
>> sub processFileMenu {
>> 	if ($option==FILENEW) {
>> 		our $newwin->{this()}=MyView();
>> 		$newwin->{this()}->show();
>> 	}
>> }
> 
>> I haven't gotten any subclasses to work with "my" variables allocated in 
>> subs, so I've been using this workaround throughout.
>>
> 
> yes. thanks. this is a good point. And a clue of what's going on. I've
> been use'ing strict so the  main:: qualifier was needed - and I tend to
> 'my' variables indiscriminately. If I just convert my 'my' to an 'our',
> then I can get one new copy of the main window to appear.

My test script also uses strict; and main:: was not needed for me.

> Strangeness re-appears when I then select File->New again. The newly
> created window disappears and a newer one appears in its place.

This is because if you just use an "our" variable, it gets overwritten 
each time through with the new MyView window.  That's why I use a hash 
keyed on the value of this() to store the references.  In a proper 
program these values may need destroyed explicitly after each window is 
closed.  I haven't looked into that.

> 
> I just tried a workaround of creating a list at global scope and pushing
> references to the new main windows onto the list as they are created.
> This prevents the garbage collection and I can now open multiple
> windows.
> 
> This is starting to make some sense now...

I also use this technique for generic subclassed controls that are 
instantiated multiple times.  If a subclassed widget creates child 
widgets in "our" variables, ever instance of the subclassed widget will 
refer to the original one's child widgets unless you use "our" hashes 
keyed on the value of this().

Hope this helps...

Darrik Mazey


More information about the Kde-perl mailing list