BR Forum

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

I regard that as a bug. I will forward this to Dan.

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

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

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

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

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

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

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!

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.

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?

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!

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?

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.

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