>>>>>>Hi,
>>>>>>
>>>>>>I am trying to find a message(s) discussing how to center a WAIT WINDOW command in a VFP window. I would be very surprised if this has never been discussed or brought up. But no matter what I enter in the UT Search, I cannot find a thread. What would you enter in the UT Search to find such a message(s)?
>>>>>>
>>>>>>TIA
>>>>>
>>>>>WAIT .. WINDOW AT Row,Col might do
>>>>>It would need to know the width of the window before, and you need to calculate it yourself. Can't remember how to figure out number of rows/columns on a screen, but this is in the help.
>>>>>Couldn't you mimic it with just showing a form with a label in it? If you need to know the width of the label to resize the form - just ask, I can post the code.
>>>>
>>>>Some potentially tricky bits
>>>>- the row and column values with the WAIT WINDOW are relative to the desktop (not the FoxPro main screen), so you'll need to adjust the position so that it follows the FoxPro main window (this can be obtained by looking at the LEFT and TOP properties of _SCREEN)
>>>>- The row and column values are based on font metrics of the main FoxPro Window
>>>>- You should able to compute the row and column values by dividing the Y coordinate with the FONTMETRIC() value for character height (you may or may not need to also include the leading value) and the X coordinate with the FONTMETRIC() value for the average character height.
>>>>- Note that FONTMETRIC uses cFontStyle representation of font style -- so you'll need to deerive this from reading the FONTITALIC, FONTOUTLINE, FONTSHADOW, FONTSTRIKETHRU and FONTUNDERLINE properties of the screen/window/control
>>>>- Multi-line WAIT window text could throw you a curve -- you won't be able to simply pass the string through TXTWIDTH() to get the width, and there isn't anything that'll tell you straight off how many rows. You can get an approximate value by using ALINES() to break the text into separate lines, then use TXTWIDTH() on each of those lines to get the widest line (in terms of average character widths -- just multiply this by the average character width from FONTMETRIC() to get pixels -- round up to next pixel value). Number of rows from ALINES() gives you height in rows of text -- multiply this by character height (you may or may not include the leading value as well) to compute the height in pixels.
>>>>- To center the WAIT WINDOW over a window, then you'll need to compute the position relative to the window by finding the difference between WAIT WINDOW width and height and the window width and height, then dividing that difference by 2 (which should give you the relative X and Y position of the WAIT WINDOW from the window). Then adjust with the LEFT and TOP value of the window to get the position relative to the FoxPro main window (i.e. _SCREEN). Then you adjust this with the LEFT and TOP value of the FoxPro _SCREEN. This should give you the X and Y coordinate you need -- which is the computed by dividing by the average character width and character height to obtain the Column and Row values.
>>>>
>>>>NOTE: The use of ALINES() is only an approximation -- It breaks lines at character positions -- so it only really works if you're using a monospace font. Of course this might not be huge problem -- if I'm not mistaken WAIT WINDOW is limited to around 254 characters anyway
>>>
>>>In simple terms, it's a pain. That's while I suggest to use a form instead of a window. Even remembering that crap ruins the day.
>>
>>Indeed. I do already have some code that I'd put into base form class to do this sort of stuff. The results vary quite a lot on conditions -- it tends to work OK as long as the user hasn't customized the screen layout. It tends to go wonky when the screen scaling or font scaling isn't set to the "normal" 100% values. I've not texted on a high-DPI display -- I'd suspect that my code would not work correctly in those circumstances.
>
>Check what VFPA can do. I code on a scaled screen, it goes better with VFPA. Customer still runs VFP9SP2 - they do not run this kind of screens. If you need to test - you can scale every screen. At least in Win10.

Might be something worth looking into.

I still have mental scars from trying to get FoxPro Windows code to work correctly -- if the screen/font scaling are different between development system and the system where program is run, the screen positions and sizes are all wonky. To compensate, I was using code snippets that overrode what the screen generator would create to compensate. It was an ugly mess as it involved converting foxel values (from development environment) to pixel and back to foxels (at runtime on client's machine). The code was rather ugly and logic was bit twisty.