Print Preview - display on top?

Discussion about printing issues and techniques.

Moderators: Susan Smith, admin, Gabriel

Post Reply
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Print Preview - display on top?

Post by Susan Smith »

Is there a way to get the print preview window (NWP, BR 4.20c) to pop up on TOP of the current BR window? I'm having a focus problem. I'm printing to preview just fine and when the printer closes the preview window pops up. But then focus instantly switches back to the BR window which pops up on top. This is a problem for users who may run at maximized screen size - they will never see the preview window. Not sure what to do.

-- Susan
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

I regard that as a bug. I will forward this to Dan.
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

John Bowman's recent comments about focus changes got me thinking and I realised something about this old dusty thread:

I think any (R)INPUT statement causes BR to grab focus, and that is why BR is grabbing the focus back from the print preview window as soon as the print preview window is opened.

Gabriel
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

This may very well be the case Gabriel, although it doesn't work the same way in all versions of BR. When I was testing 4.2 at a client, this was happening (instant focus change away from Preview). But in 4.18, it worked correctly. I decided to stay with 4.18 at my client, so we haven't had any more difficulty with this and I don't know if it still works this way in the most current version of 4.2

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Thats because in 4.18, the print preview window is Modal - it takes the focus and your program is inactive in the background until the Print Preview window is closed.

In 4.20, they made the Print Preview Window Modal, which means that the print preview window displays and your BR program is free to continue processing in the background, which of course results in a RINPUT FIELDS statement stealing the focus immediatly back from the Print Preview window.

Gabriel
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

Oh. that's right. Excellent explanation. Now I recall that you mentioned this before. I don't know how you'd solve this issue though. The problem at my client is that many of their users run BR maximized. Those users would never see a preview window and they aren't computer savvy enough that they'd think of checking the taskbar. Going back to 4.18 was our only choice.

-- Susan
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

I agree, there's no way to make it work like it is. I don't know what the solution is, either. ADS will have to change the way it works somehow.

Other languages handle this by using a "SetFocus" command that causes your application to claim the focus. But then you'd have to add SetFocus commands to your software everywhere, and none of us want to do all that..

They could make it so that INPUT statements capture focus all other times except when the focus is taken by the Modal Print Preview window. That might work..

Gabriel
Susan Smith
Posts: 717
Joined: Sun Aug 10, 2008 4:24 am
Location: Southern California

Post by Susan Smith »

I think that would be the best solution too. I can't think of ANY time that you create a print preview that you wouldn't want it to have focus. The user can always bring another BR window to focus, leaving the print preview for later if they want to.

-- Susan
Larry TIetz

Post by Larry TIetz »

I recently ran into this problem, made the input window a little smaller so the printview can be clicked on to see what's what.

At least now I know why and won't waste more time trying to figure it out!
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

Post by gordon »

In 4.20E we do the following:
  • Continue to make the PREVIEW window non-modal, but suppress the raising of the initiating window in response to waiting for keyboard entry until the PREVIEW window is closed.
Larry TIetz

Post by Larry TIetz »

If the initiating screen is maximized and fills the screen, how does the user even know there is a preview screen on which action is required?
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

gordon wrote:In 4.20E we do the following:
  • Continue to make the PREVIEW window non-modal, but suppress the raising of the initiating window in response to waiting for keyboard entry until the PREVIEW window is closed.
That sounds perfect!
Larry TIetz

Post by Larry TIetz »

OK, for those of us still in the dark ages, how do you make the printview non modal? Or suppress the initiating window until a key has been pressed?
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Larry TIetz wrote:OK, for those of us still in the dark ages, how do you make the printview non modal? Or suppress the initiating window until a key has been pressed?
Use 4.18 for the non-modal print preview window.

Use 4.20E for the modal print preview window, that has been fixed so that it works properly.
Larry TIetz

Post by Larry TIetz »

i only found 4.2D+(Debug), but that seemed to do the trick/

Also virtually instanteous vs a discernable and troublesome time delay I was experiencing with earlier 4.2
Post Reply