SCALEx and SCALEY converts wrong value. Why?

[dilettante]

The OP made it very clear that they DO want screen measurements to match real-world measurements for a drawing application.

Yes. But why? It is completely meaningless.

[OptionBase1]

I can't speak for OP, but I think wanting something to visually represent real-world measurements accurately is anything but meaningless. It may not be something you see as useful, and that's fine. But your post came off as attacking the OP for asking what you think is a stupid question or something.

I guess I didn't realize that, aside from explaining the goal of what you are trying to code, you also needed to justify why it should be done or risk getting attacked.

[dilettante]

I think he has a different problem than he believes he does. Recognizing the problem is the first step in getting help.

[OptionBase1]

I think he has a different problem than he believes he does. Recognizing the problem is the first step in getting help.

Yes, that is a fair possibility.

[Elroy]

Hmmm, well, I probably shouldn't jump into the middle of this, but I also see certain value of knowing real-world dimension of things drawn on the screen. If for no other reason (and there are others), we could show something, and say "actual size" if we got this all sorted.

Also, and dilettante's not the only one, it sort of amazes me how often someone will ask a question, and others say, "well, you shouldn't be doing it that way, and if you did it another way, you wouldn't need to ask that question". I always think, "what the heck? Who are we to tell some guy that he shouldn't be doing something the way he is?"

But hey ho. I suppose you get what you pay for on open forums.

Y'all take care,
Elroy

EDIT1: And just a but of follow-up. Sure, if someone is programming in such a way that it's a clear bug (or maybe a memory leak), sure, he needs to be told to do it differently. However, wanting a line on the screen to measure precisely 42mm (as an example) certainly doesn't fall into that category IMHO.

[ucanbizon]

Hi Elroy,

I am playing with modMonitors.bas.

I have 2 question.
1) I could not find any function to get native DPI in it. Maybe I missed.

Should I use the formula MonitorNativeResHorizPx(1)/MonitorSizeInch(1) to get it?

2) The value I get from the function TwipsPerPixelX() is the same with the value from Screen.TwipsPerPixelX and both are 15. Is the value returning from TwipsPerPixelX() function in modMonitors.bas coming from EDID data/registry entry/setup information etc or not. Are both value same coincidentally?

Because when I use the above formula [MonitorNativeResHorizPx(1)/MonitorSizeInch(1) ] I get 106.667 dpi.

Thanks in advance.

[ucanbizon]

Regarding the questions above, let me add one thing.

I have used the function MonitorEDID(1, myarray()) and get myaray() with 172 elements. I have checked out this array and could not find any native DPI information.

[Elroy]

Hi ucanbizon,

Yeah, I was wondering when you were going to get to that.

I haven't actually "thought through" all the hoops you're going to need to jump through, and there are a few.

Basically, I'm assuming that, what you're really asking in post #46 is "how do I figure out how to scale things so that an inch-is-an-inch (or a mm-is-a-mm, if you prefer). I've been tossing that one around in my head too.
There are probably a few different ways to do it, but here's how I'd approach it as a first pass.

Let's further assume that we're talking about drawing on some PictureBox of some known size (at least a known-size in terms of pixels). I made it pixels just to make it easy on us. That's easy enough. Just set our ScaleMode. To further simplify, I set my form's ScaleMode to pixels as well.

I left the borders on my PictureBox, and sized it so that the ScaleWidth and ScaleHeight were 512 & 512. (The actual Width and Height were 516 & 516, to accommodate the borders.)

So, I now know my drawing surface (my PictureBox's interior area) is exactly 512 by 512 pixels. How do I know the "real world" physical dimensions of my PictureBox? The way I'd do it is to get the resolution of my monitor, the dimensions of my monitor (via EDID), and then build two ratios (one for horizontal and another for vertical). And then, I'd use those to reset my PictureBox's ScaleWidth and ScaleHeight.

To get a particular monitor's resolution (pixel width and height), I'd use those MonitorWidthPx and MonitorHeightPx functions in the modMonitors.bas module from the CodeBank. For the sake of an example, let's say we're on a 1920 by 1080 monitor. And, we've already thoroughly discussed options for getting a monitor's physical dimensions. For the sake of an example, let's say our monitor is 521mm by 293mm. (I'll just stay in mm.)

Therefore, with this information, we could derive mmPerPixel calculations:

mmPerPixelWidth = 512mm / 1920pixels
mmPerPixelHeight = 293mm / 1080pixels

And we know our PictureBox is 512 by 512 pixels. So, we can calculate the mm of our picturebox:

mmPicBoxWidth = mmPerPixelWidth * 512
mmPicBoxHeight = mmPerPixelHeight * 512

You could then use these two numbers as your ScaleWidth and ScaleHeight, and then draw all your graphics under the assumption that you were drawing with real-world Millimeters.

PictureBox1.ScaleWidth = mmPicBoxWidth
PictureBox1.ScaleHeight = mmPicBoxHeight

(And then, draw your lines, etc, with real-world Millimeters as your units.)

I didn't think through (nor test) what's going to happen when you change your DPI settings and/or your virtualization (Windows 10) percentage, but I'm not sure they'll change anything. I'll leave that for you to explore (and probably others to comment on).

Good Luck,
Elroy

EDIT1: Basically, what we're heading toward here are a pair of functions, possibly named: MonitorMmPerPixelX & MonitorMmPerPixelY. I'd have to agree that those would be rather cool. Also, they'd need to accomodate all DPI and Win10 Scale Settings. And ideally, they'd work for both DPI-aware and DPI-not-aware.

[ucanbizon]

Hi Elroy,

Thank you again for your information. I will do my homework according to your last information and get back to here again. But It will take some time.

I have been using VB6 for about 20 years. I am 52 years old. On the other hand, my concern was never been graphical side of VB6. I am working on developing app for color matching and color receipe formulation calculation/prediction issues. Those apps are focused to heavy mathematical based calculation in it and focused for correct calculation for real world. The posh screens, amazing drawings etc are not in our focus for such app. Even a text screen (green CRT ones we used when we were young) could be enough to present our calculated data to the users, just names of dyes to be mixed and numbers about how much to be used and a few buttons "Calculate" "Exit", etc. and sometimes drawing histograms by using graph32.ocx. That all.

I'm teling this because I am almost nothing about the graphical side of VB6. This means sometimes I could be ridiculous on my questions. When I first found out that mm in VB6 (or windows) is not mm in real world, I was very surprised. Then why all those options in scalemode is there? Anyway this is not a question to get answer, just talking to myself.

Just to remind you, why we need so complicated ways to get true size lines etc you mentioned in post #48. What's wrong with the way/formula I asked in my post #46 to get real DPI? ---> MonitorNativeResHorizPx(1)/MonitorSizeInch(1) ?

[Elroy]

Hi ucanbizon,

So, you're a youngster. I'm in my 60s. We reminisce on here sometimes about our TRS-80-Model-I days with our tape machines as our storage devices, or our 14" hard disk platters that held a whopping 5MB.

And well, regarding high-level graphing and image manipulation, I'm not the absolute expert. I muddle through to get the things done I need to do. I'm fairly strong with some of the math stuff though: Not sure if you've seen my 3D linear algebra routines in the codebank. Also, I've played around in the past with colors, specifically developing the math for color pickers, and converting RGB to HSV and/or HSL (and vice-versa). Many moons ago, I even did an old Fortran project using a mouse on an old CP/M S100 bus system that used the old CIE 1931 color space diagram. It was for a seismic data analysis workstation.

As an interesting story, one of my partners back then went on to develop the original AutoTune system that's used by musicians. It turns out that analyzing seismic data isn't that different from analyzing human sound.

Well anyway, back to your problem. Ok, you actually did ask a question: "What's wrong with the way/formula I asked in my post #46 to get real DPI? ---> MonitorNativeResHorizPx(1)/MonitorSizeInch(1) ?" Ok, first, that MonitorNativeResHorizPx is coming out of the EDID, and has nothing to do with the user's settings for the monitor. Are you going to force your users to use the monitor's native resolution? If you are, I've got other code that could check it, and "force" that, and/or reset it. That's not a terribly nice thing to do though, and some users may get annoyed.

The MonitorMmPerPixelX & MonitorMmPerPixelY calls report the monitor's "settings" as opposed to its "capabilities". Just to be clear, the "native" resolution is when your hardware-pixels perfectly correspond to your software-pixels. It's also listed as the "recommended" resolution under settings...



However, as a "cheat" way to get magnification, many users will often use a lower setting. If you use the MonitorMmPerPixelX & MonitorMmPerPixelY calls, these lower (software) settings will be reported. But the MonitorNativeResHorizPx & MonitorNativeResVertPx will always report that "recommended" setting, even if that's not what's being used.

I hope that helps.

Since it's a bit exciting, I'll probably eventually develop those MonitorMmPerPixelX & MonitorMmPerPixelY functions. However, I'm not going to make any timeframe promises. I've actually got "real work" on my plate, and I don't have any immediate need for that functionality at the moment. It does sound like a fun project though. I did outline it in post #48, but I'm pretty sure all the DPI <> 100% and/or Win10 Scaling and/or DPI-aware vs not issues would work correctly. If the MonitorMmPerPixelX & MonitorMmPerPixelY functions are used, I do know that the resolution setting wouldn't be an issue.

You Take Care,
Elroy

[ucanbizon]

So, you're a youngster. I'm in my 60s. We reminisce on here sometimes about our TRS-80-Model-I days with our tape machines as our storage devices, or our 14" hard disk platters that held a whopping 5MB.

A computer with a hadrdisk? WOW! Amazing

I remember, when I was a student at the university, there was an IBM mainframe and we were using punched cards to program it via FORTRAN IV. One punched card for each line/command at a time. After a year, the punched card machines gone and new floopy machines come. The unit only to write something to a floopy was bigger then a car dimension.

And my first PC at about 20 years old was a RadioShack with a single 5 1/4 inch floopy (360kb), 256 kb memory, no hard drive, a green texted CRT monitor.

Take care and best regards.

[Magic Ink]

Ucan - You may be asking yourself why screen objects support ScaleMode Inches, Centimeters at all if individual target screens have so much difficultly in showings things actual size. If you are not asking yourself that then ignore this post.

One useful reason is that the vb Printer object shares the same properties and DOES obey the rules as one may expect.

So if we do;

Printer.ScaleMode = VbInches
Printer.Line (10,5)-(15,5)

we get a horizontal line drawn which IS actually 5 inches long and 5 inches down from the top of the paper.

If we do

Picture1.ScaleMode = VbInches
Picture1.Line (10,5)-(15,5)

however, we get a horizontal line drawn on the PictureBox which may not be 5 inches long, 5 inches down due to DPI setting, Screen resolution, Monitor size, Pixel pitch etc.
However the screen image is still a very useful scaled preview of what you get when it is printed.

Taking the above further we can use the same code to send drawing content to the Picture or the Printer by wrapping the drawing code inside a single Sub and supply the object to draw to in its parameters.
So we make;

Sub Drawstuff (PDevice as Object)
PDevice .ScaleMode = VbInches
PDevice .Line (10,5)-(15,5)
End Sub

Thus when we want to draw to the Picture (preview) we call the Sub with

DrawStuff Picture1

and when we want to print it (actual size) to paper we do

Drawstuff Printer

Stuff like this saves us using two versions of near identical code.

So if we are dealing with drawings where size matters the essence is that if you can produce a hardcopy printed version at real actual size, it really does not matter what size it is displayed at onscreen. The only real purpose of a drawing produced at actual size is that you can scale off it physically using a ruler, callipers etc, and that is difficult on a vertically orientated monitor. So why not just display the screen image at a convenient and probably bigger size than actual.

Or perhaps you can explain exactly why the screen image you require must be at actual size.

[Elroy]

@dilettante: Here's a question for you. When using the setupapi.dll approach to getting the EDID information, how do we get the monitor handles (hMonitor) for the returned enumerated list?

I'm on my way to tracking down the answer, but I'm also curious as to what your answer will be.

[dilettante]

I'm pretty sure you can't. Even if you do it would be unreliable.


The EDID data is part of the state and configuration information stored by a display adapter driver. It gets used to "create" a monitor (with an hMonitor handle) during driver initialization at boot and as device arrival is detected.

Your question is almost like: "How can I get a reference to some arbitrary class instance, when I can find its ClassID or ProgID in the registry?"

The EDID info is just part of the template used to create the NT software object "Monitor" at run time and has a handle of that type.


Try it:

Take a program that can report the current monitor its Form is on, its dimensions and work area dimensions, etc. Run that in a Remote Desktop session... sure enough it works.

Then take a program that reports the EDID data for each monitor and run it on the RDP server. If no physical monitors are connected you get no hits at all.

[ucanbizon]

Hi,

Regarding to the persistent question whay do I need to draw shapes (lines, circles, rectangles, squares etc) with true metric size on the screen;

There are A4 (sometimes bigger) tranparent papers pre-printed "actual-sized" shapes on it. You may think those papers as layers like the navigation and map apps have. But this not a navigation or map app.

The user will draw a set of shapes on the screen and then put one or more those layers (pre-printed transparent papers) on the screen to see the final result (like blending two or more images). If the user decide it is ok, the data drawn on the screen via my app will be sent to a production machine's PLC via RS232 serial port with a set of certain protocol we will diecide later.

So, everything on the screen should be axactly true-sized. Hope I have achived clarity.


The modmonitor.bas give me screen size correctly. I have tried it also with a few diffrent PC with different size monitors. All are ok. I think it will be ok unless the PC is with very old-aged monitors. Now, I am continuing to develope the app based on functions in modmonitors.bas.

PxPerMM_X = (MonitorNativeResHorizPx(1) / MonitorWidthInch(1)) / 25.4 '%100
PxPerMM_Y = (MonitorNativeResVertPx(1) / MonitorHeightInch(1)) / 25.4 '%100


On the other hand, to be sure about the monitor size, you are definitly suggesting to measure the screen with a ruler. Of course this is best way but hard to apply. How to be sure that a measurement with a ruler is precise enough by the users.

By the way, while contuining to develope the app according the above basis, on the other hand I am thinking a new approach to calibrate the app for "true size" matter.

I may add a calibration menu in the app. I can force them to prepare one calibration sheet (transparent) with one vertical and one horizantal line at a certain lenght (say 100mm) on it. When the user enters in that menu, a single line with 100 pixels horizantal and 100 pixels vertical line will be displayed on the screen automatically. And there will also be + and - buttons to scale both lines seperatelly. The user will adjust the lengths of the lines via + and - buttons until it fits the lines on the screen to the ones pre-printed lines on transparent papers. And press save (or calibrate) button and I will learn how many pixels for a mm is being used for that monitor particularly.

Thank you to all who are dealing with the this topic and also the others who shares the solutions for related matters at other topics as well.Each comment is taking me to a one level up guys.

Take care and stay tuned.

[ucanbizon]

Hi, It's me again.

I have 2 questions. First one is to Elroy and the second one is to the ones who wish to answer.

1) Hi Elroy, Please let me have your answer to my question at post #47.

2) I have tried to calculate DPI values (NativeResolution/ScreenWitdh) on a few monitors in my hand and seen that vertical DPI and horizantal DPI are always same. Can we say that it is always same for all monitors.?

Take care
Hakan