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. |
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. > > |
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. > > > > |
> 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 - |
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 > - > > |
Free forum by Nabble | Edit this page |