Hello Everyone.

Man am I having trouble with co-ordinates.

I want to be able to specify the location of a dialogue box (at runtime)
by a user inputing the top, left, width and height co-ordinates of the
dialogue box (via another dialogue box). So far I have been able to do
this using all the standard co-ordinate settings (twips??). So the
dialogue box is moving around just like I want it to, but...

I don't like twips. I want the co-ordinate system to be 600 high by 800
wide (this is the client area of the MDI parent, right?). I then want to
be able to say put the top left corner of the dialogue box at 100 units in
from the left and 100 units down from the top and make the dialogue box
200 units wide and 100 units high, thank you very much.

At present my main form is an MDI form. I'm not even sure this is the
right approach.

Any assistance would be met with a great deal of pathetic gratitude.

Thanks,

Kurt

[snip]

[snip]

Let your user enter the coordinates in pixels and then convert their
entry to twips.  I think there are about 14 or 5 twips to the pixel,
but it would be best to calculate that at run time.  Check the
TwipsPerPixelX and TwipsPerPixelY properties of the Screen object in
the Language Reference.
---------------------------------

ArlTex Software
Arlington, Texas USA
http://rampages.onramp.net/~n5ge/
---------------------------------

No, that's the size of YOUR screen, mine is presently 1024x768.

Well, you're forcing the coordinates to your screen dimensions which
is not the same as every other screen your code might run under. You
have a few options, look up the twips per pixel conversions (see the
Screen object, I think...I use the API "metrics" calls myself) and
determine what the screen dimensions are and adjust accordingly. The
cheap and easy route (but less flexible) is to work everything off
of the ratio of the current screen. That is 0-100% of Screen.Width and
Screen.Height. You can easily get the percent from a scroll bar and
convert to a percent, then multiply this times Screen.Width and
Screen.Height.

There are better solutions which are more complicated, but this is
simple and has low overhead.

--fran

! F.G. Kostella & Associates ** Design, Programming, Graphics