PDA

View Full Version : New auto locate mixin for multiple monitors



matthewd
27-Mar-2008, 04:21 PM
I started working on a "final" fix for this at DISD after someone asked
John Tuohy about it (yet again!). I just finished it up and it is now
ready to be let loose in the wild.

To recap the saga so far:

The auto locate logic in DAW's autolcmx.pkg fails on multiple monitors,
especially when a secondary monitor is placed to the left or above the
primary monitor. The reason is that monitor has negative coordinates,
which autolcmx doesn't think are valid (and they weren't before dual
monitors were possible). So when you are running an app on the
secondary monitor, a lookup or dialog that is set to autolocate will
appear on the primary monitor instead of the secondary monitor.

I implemented a partial fix years ago. It involved getting the top left
coordinates of the "virtual" screen. This allowed lookups to be auto
located correctly on the secondary monitor.

But it did not address at least two issues:

When monitors are different resolutions, dialogs can be clipped on the
smaller monitor, or half of the lookup could appear on each monitors.

CENTER_ON_SCREEN just didn't work at all, since it always placed the
dialog on the primary monitor, instead of the monitor that the
application is running on (as you would expect). You can see this
behavior in Database Builder for instance.

The new logic in the attached package gets the monitor information from
Windows and uses this to center dialogs on the proper screen and
position dialogs so that they are not clipped.

It is designed as a mixin class, so usage goes something like this in
your modal panel subclass:

Use auto_locate_mx.pkg

Class mydbModalPanel is a dbModalPanel

Import_Class_Protocol cAutoLocateMixin

Procedure Construct_object
forward send Construct_object
send Define_cAutoLocateMixin
End_procedure
....
End_class

In addition, there are three new locate modes implemented:

CENTER_ON_PRIMARY - Always center on the primary monitor

CENTER_ON_SECONDARY - Always center on the first secondary monitor that
is found, if none is found, center on the primary monitor

CENTER_ON_MONITOR - Center on the monitor identified by the property
phMonitor, a handle to a monitor

If you want to see how to obtain a monitor handle, examine the
monitor.pkg file (which has a procedure to enumerate all monitors)

This was developed and compiled under 12.1, but I see no reason it
shouldn't work on VDF versions going back to 8.x.

Now we just need to mount a campaign to get DAW to use this package to
fix the issues with the Studio and Database Builder.

--
Best Regards,

Matthew Davidian
Datatech
Fresno, CA
http://www.DatatechAg.com

Dan Walsh
29-Mar-2008, 11:27 AM
Sign me up Matt. Thanks.

Matthew Davidian wrote:
> I started working on a "final" fix for this at DISD after someone asked
> John Tuohy about it (yet again!). I just finished it up and it is now
> ready to be let loose in the wild.
>
> To recap the saga so far:
>
> The auto locate logic in DAW's autolcmx.pkg fails on multiple monitors,
> especially when a secondary monitor is placed to the left or above the
> primary monitor. The reason is that monitor has negative coordinates,
> which autolcmx doesn't think are valid (and they weren't before dual
> monitors were possible). So when you are running an app on the
> secondary monitor, a lookup or dialog that is set to autolocate will
> appear on the primary monitor instead of the secondary monitor.
>
> I implemented a partial fix years ago. It involved getting the top left
> coordinates of the "virtual" screen. This allowed lookups to be auto
> located correctly on the secondary monitor.
>
> But it did not address at least two issues:
>
> When monitors are different resolutions, dialogs can be clipped on the
> smaller monitor, or half of the lookup could appear on each monitors.
>
> CENTER_ON_SCREEN just didn't work at all, since it always placed the
> dialog on the primary monitor, instead of the monitor that the
> application is running on (as you would expect). You can see this
> behavior in Database Builder for instance.
>
> The new logic in the attached package gets the monitor information from
> Windows and uses this to center dialogs on the proper screen and
> position dialogs so that they are not clipped.
>
> It is designed as a mixin class, so usage goes something like this in
> your modal panel subclass:
>
> Use auto_locate_mx.pkg
>
> Class mydbModalPanel is a dbModalPanel
>
> Import_Class_Protocol cAutoLocateMixin
>
> Procedure Construct_object
> forward send Construct_object
> send Define_cAutoLocateMixin
> End_procedure
> ....
> End_class
>
> In addition, there are three new locate modes implemented:
>
> CENTER_ON_PRIMARY - Always center on the primary monitor
>
> CENTER_ON_SECONDARY - Always center on the first secondary monitor that
> is found, if none is found, center on the primary monitor
>
> CENTER_ON_MONITOR - Center on the monitor identified by the property
> phMonitor, a handle to a monitor
>
> If you want to see how to obtain a monitor handle, examine the
> monitor.pkg file (which has a procedure to enumerate all monitors)
>
> This was developed and compiled under 12.1, but I see no reason it
> shouldn't work on VDF versions going back to 8.x.
>
> Now we just need to mount a campaign to get DAW to use this package to
> fix the issues with the Studio and Database Builder.
>

Michel Boisvert
12-Jun-2008, 04:24 PM
we had to comment the "fudge factor" to make it work properly on our
dual screen set-up ???

// // we use 2 a a pixel fudge factor...looks better
// Move ( Hi(ScreenSz)) to sHt
// Move (Low(ScreenSz)) to sWd
// //
// If (Row+Ht>sHt) Move (sHt - Ht - 2 ) to Row
// If (Col+Wd>sWd) Move (sWd - Wd - 2 ) to Col
// If (Col<iXTopLeft) Move (iXTopLeft+2) to Col
// If (Row<iYTopLeft) Move (iYTopLeft+2) to Row

works fine now. Thanks.