Alert.open()

[Scott Lanham <li...@sael.com.au>]

Hi,

Was it intentional to change Alert.open() so that only a Display could be 
passed as the first argument  instead of a Window?

Thanks,

Scott.

Re: Alert.open()

[Greg Brown <gk...@mac.com>]

Yes. That change was made to address PIVOT-297:

http://issues.apache.org/jira/browse/PIVOT-297

On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:

> Hi,
>
> Was it intentional to change Alert.open() so that only a Display  
> could be
> passed as the first argument  instead of a Window?
>
> Thanks,
>
> Scott.

Re: Alert.open()

[Greg Brown <gk...@mac.com>]

Yes.

On Sep 16, 2009, at 5:16 PM, Scott Lanham wrote:

> Do the Alert.alert static functions take care of this?
>
> On Thu, 17 Sep 2009 07:04:23 am Greg Brown wrote:
>> More importantly, you may need to clear the Alert's owner when it
>> closes. If you instantiate the Alert once and keep it around for the
>> lifetime of your application, you probably don't need to do that, but
>> if your instantiates the Alert every time you need to open it, you
>> will need to clear the owner. Otherwise, you will trigger the memory
>> leak (since the owner will retain a reference to the window even
>> though you have already released it).
>>
>> On Sep 16, 2009, at 5:01 PM, Greg Brown wrote:
>>> Note that you now need to specify the Alert's owner by a call to
>>> setOwner() before you call open(). I know this is less convenient
>>> than the open(Window) method, but we had to eliminate that method
>>> because it was a source of memory leaks. We gave a lot of thought to
>>> other solutions, but we felt that eliminating the problem methods
>>> altogether was the cleanest solution. It is also consistent with how
>>> similar APIs in Windows and GTK work (which also require the caller
>>> to manually set the window owner).
>>>
>>> Hopefully this change doesn't require too much rework on your part.
>>> Let us know if you have any questions or run into any issues.
>>>
>>> G
>>>
>>> On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:
>>>> Hi,
>>>>
>>>> Was it intentional to change Alert.open() so that only a Display
>>>> could be
>>>> passed as the first argument  instead of a Window?
>>>>
>>>> Thanks,
>>>>
>>>> Scott.
>

Re: Alert.open()

[Scott Lanham <li...@sael.com.au>]

Do the Alert.alert static functions take care of this?

On Thu, 17 Sep 2009 07:04:23 am Greg Brown wrote:
> More importantly, you may need to clear the Alert's owner when it
> closes. If you instantiate the Alert once and keep it around for the
> lifetime of your application, you probably don't need to do that, but
> if your instantiates the Alert every time you need to open it, you
> will need to clear the owner. Otherwise, you will trigger the memory
> leak (since the owner will retain a reference to the window even
> though you have already released it).
>
> On Sep 16, 2009, at 5:01 PM, Greg Brown wrote:
> > Note that you now need to specify the Alert's owner by a call to
> > setOwner() before you call open(). I know this is less convenient
> > than the open(Window) method, but we had to eliminate that method
> > because it was a source of memory leaks. We gave a lot of thought to
> > other solutions, but we felt that eliminating the problem methods
> > altogether was the cleanest solution. It is also consistent with how
> > similar APIs in Windows and GTK work (which also require the caller
> > to manually set the window owner).
> >
> > Hopefully this change doesn't require too much rework on your part.
> > Let us know if you have any questions or run into any issues.
> >
> > G
> >
> > On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:
> >> Hi,
> >>
> >> Was it intentional to change Alert.open() so that only a Display
> >> could be
> >> passed as the first argument  instead of a Window?
> >>
> >> Thanks,
> >>
> >> Scott.

Re: Alert.open()

[Greg Brown <gk...@mac.com>]

Yes.

On Sep 16, 2009, at 5:14 PM, Scott Lanham wrote:

> Do you clear the owner by calling setOwner( null )?
>
> On Thu, 17 Sep 2009 07:04:23 am Greg Brown wrote:
>> More importantly, you may need to clear the Alert's owner when it
>> closes. If you instantiate the Alert once and keep it around for the
>> lifetime of your application, you probably don't need to do that, but
>> if your instantiates the Alert every time you need to open it, you
>> will need to clear the owner. Otherwise, you will trigger the memory
>> leak (since the owner will retain a reference to the window even
>> though you have already released it).
>>
>> On Sep 16, 2009, at 5:01 PM, Greg Brown wrote:
>>> Note that you now need to specify the Alert's owner by a call to
>>> setOwner() before you call open(). I know this is less convenient
>>> than the open(Window) method, but we had to eliminate that method
>>> because it was a source of memory leaks. We gave a lot of thought to
>>> other solutions, but we felt that eliminating the problem methods
>>> altogether was the cleanest solution. It is also consistent with how
>>> similar APIs in Windows and GTK work (which also require the caller
>>> to manually set the window owner).
>>>
>>> Hopefully this change doesn't require too much rework on your part.
>>> Let us know if you have any questions or run into any issues.
>>>
>>> G
>>>
>>> On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:
>>>> Hi,
>>>>
>>>> Was it intentional to change Alert.open() so that only a Display
>>>> could be
>>>> passed as the first argument  instead of a Window?
>>>>
>>>> Thanks,
>>>>
>>>> Scott.
>

Re: Alert.open()

[Scott Lanham <li...@sael.com.au>]

Do you clear the owner by calling setOwner( null )?

On Thu, 17 Sep 2009 07:04:23 am Greg Brown wrote:
> More importantly, you may need to clear the Alert's owner when it
> closes. If you instantiate the Alert once and keep it around for the
> lifetime of your application, you probably don't need to do that, but
> if your instantiates the Alert every time you need to open it, you
> will need to clear the owner. Otherwise, you will trigger the memory
> leak (since the owner will retain a reference to the window even
> though you have already released it).
>
> On Sep 16, 2009, at 5:01 PM, Greg Brown wrote:
> > Note that you now need to specify the Alert's owner by a call to
> > setOwner() before you call open(). I know this is less convenient
> > than the open(Window) method, but we had to eliminate that method
> > because it was a source of memory leaks. We gave a lot of thought to
> > other solutions, but we felt that eliminating the problem methods
> > altogether was the cleanest solution. It is also consistent with how
> > similar APIs in Windows and GTK work (which also require the caller
> > to manually set the window owner).
> >
> > Hopefully this change doesn't require too much rework on your part.
> > Let us know if you have any questions or run into any issues.
> >
> > G
> >
> > On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:
> >> Hi,
> >>
> >> Was it intentional to change Alert.open() so that only a Display
> >> could be
> >> passed as the first argument  instead of a Window?
> >>
> >> Thanks,
> >>
> >> Scott.

Re: Alert.open()

[Greg Brown <gk...@mac.com>]

More importantly, you may need to clear the Alert's owner when it  
closes. If you instantiate the Alert once and keep it around for the  
lifetime of your application, you probably don't need to do that, but  
if your instantiates the Alert every time you need to open it, you  
will need to clear the owner. Otherwise, you will trigger the memory  
leak (since the owner will retain a reference to the window even  
though you have already released it).

On Sep 16, 2009, at 5:01 PM, Greg Brown wrote:

> Note that you now need to specify the Alert's owner by a call to  
> setOwner() before you call open(). I know this is less convenient  
> than the open(Window) method, but we had to eliminate that method  
> because it was a source of memory leaks. We gave a lot of thought to  
> other solutions, but we felt that eliminating the problem methods  
> altogether was the cleanest solution. It is also consistent with how  
> similar APIs in Windows and GTK work (which also require the caller  
> to manually set the window owner).
>
> Hopefully this change doesn't require too much rework on your part.  
> Let us know if you have any questions or run into any issues.
>
> G
>
> On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:
>
>> Hi,
>>
>> Was it intentional to change Alert.open() so that only a Display  
>> could be
>> passed as the first argument  instead of a Window?
>>
>> Thanks,
>>
>> Scott.
>

Re: Alert.open()

[Greg Brown <gk...@mac.com>]

Note that you now need to specify the Alert's owner by a call to  
setOwner() before you call open(). I know this is less convenient than  
the open(Window) method, but we had to eliminate that method because  
it was a source of memory leaks. We gave a lot of thought to other  
solutions, but we felt that eliminating the problem methods altogether  
was the cleanest solution. It is also consistent with how similar APIs  
in Windows and GTK work (which also require the caller to manually set  
the window owner).

Hopefully this change doesn't require too much rework on your part.  
Let us know if you have any questions or run into any issues.

G

On Sep 16, 2009, at 4:32 PM, Scott Lanham wrote:

> Hi,
>
> Was it intentional to change Alert.open() so that only a Display  
> could be
> passed as the first argument  instead of a Window?
>
> Thanks,
>
> Scott.