Printer Dialog lost behind form?
Using latest fast reports...
Use Delphi 10 Seattle
I gave the ability to show printer dialog during report printing
Some complain the Dialog is getting lost behind the program, and end up just end tasking it.
Not sure if this is curable or not ?
Use Delphi 10 Seattle
I gave the ability to show printer dialog during report printing
Some complain the Dialog is getting lost behind the program, and end up just end tasking it.
Not sure if this is curable or not ?
Comments
Is there something special in the set-up of the users complaining?
Nothing special at all... we have 121 customer locations across the country (and counting) running our software. Each location usually has 5 - 20+ terminals running it all day long.
Only a few random places have this issue, and seems to only be 1 or 2 machines that do it.... AND ...... it doesn't happen all the time.
I have 7 fast reports they can use.
Whenever it happens, our support tem gets me remoted in to test it... and never repeatable. Never...
I've done hundreds of prints here at office trying to repeat steps im told... nothing happens out of the ordinary.
Systems its happened on is XP (not many left on these luckly it seems), Win7, Win10 ....
Its like the modal window shows... but not visible. They alt tab... nothing happens. I Assume behind the main form window which is usually always maximized.
So they can't close/click it to move it or anything.
So not sure what to do
Are the problem machines dual-screen setups or laptops which sometimes have a second screen?
I suggest that the following is tried when it occurs, which may also work if it is a stacking issue like you suspect:
<Alt>-<tab> around until the offending program is active (if not already)
<Alt>-<space> to activate the window menu
M for move - if the mouse cursor vanishes it has probably gone off-screen
<up-arrow>
If the mouse is then moved the dialog will hopefully appear hanging on the mouse cursor - click to place
I can tell our techs to try this and see what happens..... if it works, nice, but not really a fix .... but at least a clue to whats going on maybe?
Looking at the frxPrintDialog source.... maybe something to be had with PopupMode, DefaultMonitor, Position, OldCreateOrder ?
Our app is a deal that is ran maximized at all times pretty much... And multiple tab interface deal too... (Sorta like browser tabs) ... so lots of embedded
forms/frames/blah ...
So pondering if that sometimes fools with the popup form on trying to figure out where it needs to go?
Our solution was to parent the dialog again just before the showing if it were a modal dialog, we couldn't fix it for non modals. So far I can tell it has to do with the z buffering of the windows.
We have a FEW locations that use Terminal Services..... but for the most part, the mass majority just have actual full fledge windows machines for each worker, and as far as I know and checked on, have all been
true windows machines... not Terminal based like Citrix or Terminal Services ...
I can modify the source.... but that would stink as i would have to maintain it forever...