[7.5] Native dialogs behind windows?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[7.5] Native dialogs behind windows?

Boris Popov, DeepCove Labs (SNN)
Does anyone have a clue why native file dialogs often come up behind an
active VisualWorks window? I can't seem to come up with a consistently
reproducible case, but certainly I've been seeing this behavior for a
while now on a variety of versions so I must not be alone here?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

RE: [7.5] Native dialogs behind windows?

Steven Kelly
One clue (and that's all it is) is that Windows likes to know the window
handle of the parent window for the dialog. IIRC we found that supplying
the parent handle significantly reduced the risk that the dialog would
end up under its parent window. Supplying the parent handle also for
some reason corrected the Windows print dialog in XP from the old
98/2000 look to the XP look.

HTH,
Steve

> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: 20. elokuuta 2007 18:41
> To: VWNC
> Subject: [7.5] Native dialogs behind windows?
>
>
> Does anyone have a clue why native file dialogs often come up
> behind an active VisualWorks window? I can't seem to come up
> with a consistently reproducible case, but certainly I've
> been seeing this behavior for a while now on a variety of
> versions so I must not be alone here?
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the
> message header. Unless otherwise indicated, it contains
> information that is private and confidential. If you have
> received it in error, please notify the sender and delete the
> entire message including any attachments.
>
> Thank you.
>
>

Reply | Threaded
Open this post in threaded view
|

RE: [7.5] Native dialogs behind windows?

Boris Popov, DeepCove Labs (SNN)
That makes sense, however I'd expected that default behavior would be to
at least try and find a handle to use if one wasn't passed explicitly
via the #for: API, say
 
Window activeController view

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Steven Kelly [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 8:56 AM
> To: VWNC
> Subject: RE: [7.5] Native dialogs behind windows?
>
> One clue (and that's all it is) is that Windows likes to know the
window
> handle of the parent window for the dialog. IIRC we found that
supplying

> the parent handle significantly reduced the risk that the dialog would
> end up under its parent window. Supplying the parent handle also for
> some reason corrected the Windows print dialog in XP from the old
> 98/2000 look to the XP look.
>
> HTH,
> Steve
>
> > -----Original Message-----
> > From: Boris Popov [mailto:[hidden email]]
> > Sent: 20. elokuuta 2007 18:41
> > To: VWNC
> > Subject: [7.5] Native dialogs behind windows?
> >
> >
> > Does anyone have a clue why native file dialogs often come up
> > behind an active VisualWorks window? I can't seem to come up
> > with a consistently reproducible case, but certainly I've
> > been seeing this behavior for a while now on a variety of
> > versions so I must not be alone here?
> >
> > Cheers!
> >
> > -Boris
> >
> > --
> > +1.604.689.0322
> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> > http://tinyurl.com/r7uw4
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the
> > message header. Unless otherwise indicated, it contains
> > information that is private and confidential. If you have
> > received it in error, please notify the sender and delete the
> > entire message including any attachments.
> >
> > Thank you.
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: [7.5] Native dialogs behind windows?

Reinout Heeck

> That makes sense, however I'd expected that default behavior would  
> be to
> at least try and find a handle to use if one wasn't passed explicitly
> via the #for: API, say
>
> Window activeController view


It does, using
   Window currentWindow


I looked at the references to the underlying shared and saw

Window>>becomeInactive

        LockCurrentWindow critical:
                [CurrentWindow == self
                        ifTrue: [CurrentWindow := nil]]



This suggests that it only happens right after closing a window.

Could it be that this problem only shows up if the native dialog is  
opened in response to a preceding warning or choice dialog? I cannot  
test it right now, no mswindows here.



R
-

Reply | Threaded
Open this post in threaded view
|

RE: [7.5] Native dialogs behind windows?

Steven Kelly
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Possibly interesting bug correction mentioned in the latest internal
build:

GUI
        51311 Window>>currentWindow is nil after opening window from
launcher menu.

Steve

> -----Original Message-----
> From: Reinout Heeck [mailto:[hidden email]]
> Sent: 20. elokuuta 2007 20:46
> To: VWNC
> Subject: Re: [7.5] Native dialogs behind windows?
>
>
>
> > That makes sense, however I'd expected that default behavior would
> > be to
> > at least try and find a handle to use if one wasn't passed
> explicitly
> > via the #for: API, say
> >
> > Window activeController view
>
>
> It does, using
>    Window currentWindow
>
>
> I looked at the references to the underlying shared and saw
>
> Window>>becomeInactive
>
> LockCurrentWindow critical:
> [CurrentWindow == self
> ifTrue: [CurrentWindow := nil]]
>
>
>
> This suggests that it only happens right after closing a window.
>
> Could it be that this problem only shows up if the native dialog is  
> opened in response to a preceding warning or choice dialog? I cannot  
> test it right now, no mswindows here.
>
>
>
> R
> -
>
>