mrow/mcol vs position in pixels

[Olaf Doschke]

I think I had the same problem as Mike in thread184-1263466 and I came to a new observation.

ACTIVATE POPUP xyz AT MROW(),MCOL() works nice within the IDE, but not at runtime. The difference is not scalemode of the form or screen, nor is it the missing parameterisation with a scalemode, the difference is made by the _screen.font. It default to FoxFont at runtime, while you surely have set Arial at designtime - within the IDE.

And that makes the difference.

No need to compute rows/cols from pixel coordinates etc. You can continue to use the simple MROW(),MCOL() or explicitly MROW(0,0), MCOL(0,0) for activating a shortcut/context menu at mouse position, if you just set _screen.fontname="Arial".

Bye, Olaf.

 

[Mike Lewis]

Olaf,

First, thanks for reminding me about this issue. The thread you referenced is over five years old now. It's interesting to re-visit it.

Your point about the different _SCREEN.Fontname in the IDE is a revelation. It never occurred to me that that was the case. I can see now why my first attempts were giving bad results.

For what it's worth, here how I eventually solved the problem. To recap, my aim was to find the FROM and TO values for a DEFINE POPUP command, when I wanted to pop up the menu at a specific location rather than at the mouse pointer. Specifically, I wanted to "attach" a menu to a button, so that when the user clicked the button, the menu popped up just below the button, and aligned to its left edge.

This is an extract of the code I used in a custom GetMenuPosition of the button:

* Left co-ordinate of the menu
lnLeft = (OBJTOCLIENT(this, 2) + thisform.Left + SYSMETRIC(3))

* Right co-ordinate of the menu
lnRight = OBJTOCLIENT(this, 1) + this.Height + thisform.Top + ;
            SYSMETRIC(9) + SYSMETRIC(4)

In both cases, the co-ordinate is relative to the client area of _SCREEN, which is what I wanted. The co-ords are in pixels, so I then converted to Foxels using the code I showed in the orginal thread. It was that code that had given me so much trouble, for the reasons that Olaf has now pointed out. But I got it working in the end.

Interestingly, although I had completely forgotten all about the problem, I've used the menu button a thousand times in my applications since then. The code is simply there, at class level, without the need for anyone ever to look at it. Such is the wonder of encapsulation.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[craigber]

Makes total sense to me. Foxfont is mono-spaced, so the width of every character is the same. Arial is proportional, meaning a narrow character like i uses less width onscreen than a w. Point size refers to the height of the font. As you change point size, the width is then automatically changed so the font looks proportionally sized. As for pixels, resolution, DPI, etc, they're also variables. Markus Egger blogged about it several years ago.

http://www.markusegger.com/Articles/Article.aspx?quickid=060083.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

I find it easier to use MROW() MCOL() as given current mouse positions, but indeed found further problems.
First of all what matters is, that form.fontname is identical to _screen.fontname. It doesn't matter, whether the font is monospaced or not.

In my case a click on a context menu item opens a form at mouse position, too, that's another issue, but doesn't matter here, just to mention I also defined the popup with the same font and font size, which also is important, most probably.

There still are some quirks or I made mistakes in updating EXE versions, but I had the effect of this working sometimes and simetimes not, this is really a bummer.

Yes, it's quite an old issue, but after I found the dependance on the font I searched here for FOXFONT and MROW and came up with this thread solving the issue by pixel coordinate translations. I assume there is a chapter on this in some books, too. I just felt I would share this experience, as it's hard to grip, that the font matters. But indeed the coordinate system of rows and cols is depending on the font(s) used. It's natural once you think about the nature of the old foxpro foxels and rows and columns in the legacy foxpro screens. I also assume _screen.scalemode and form.scalemode may play a role, but with scalemode 0 (foxels) your form controls will not be at the positions and size you're used to, you'll find that out very fast, if you try it.

Bye, Olaf.

 

[Olaf Doschke]

The problem is still not yet totally gone.

fonts are equal, even the shrtcut menu font, and I define it as

DEFINE PUPOP xyz SHORTCUT RELATIVE FROM 0,0

Then later do

ACTIVATE POPUP xyz AT MROW(), MCOL()

Now I displayed the position in a wait window to debug it, comparing with known positions:

lnRow = MROW(0,0)
lnCol = MCOL(0,0)
WAIT WINDOW TRANSFORM(lnRow)+" ; "+TRANSFORM(lnCol) NOWAIT
ACTIVATE POPUP xyz AT lnRow, lnCol

That positions the context menu correctly, but as soon as I remove the wait the positioning will shift again. So it may have to do with the wait window moving focus forth and back. Earlier I debugged with ACTIVATE SCREEN and showing values with the ? command. It's really weird, but I tend to move to the more reliable pixel coordinates I may also get from Windows API and calculate the row/col from that myself.

The funny part is, even on the same form showing a shortcut context menu works via MROW and MCOL, even for years of not caring about screen or form font. The only mentionable difference is the long time working control is a OLE control, what does not work is activating the shortcut from the rightclick of a VFP Editbox. OLE contrlls have their own HWND, so that may have to do with that.

Bye, Olaf.