Get Usable Monitor Size

[Hooovahh]

---

@Kyle97330 wrote:

So it does appear to work on all monitors... 

---

Yup that's what I said, which is also why I marked it as the solution.  The thing that doesn't work on all monitors is the native LabVIEW Display >> Primary Workspace, this only works on the primary workspace, the main monitor.

[johnsold]

This also seems to work. Two property nodes. Application >> Display: All Monitors and VI >> FP.Monitor and FP.Panel Bounds. On the Mac FP.Monitor returns 1 or 2 for primary or secondary monitor. The help indicates that Windows uses other values.

In the image below the VI was running on the secondary monitor which is logically to the left and bottom aligned with respect to the primary monitor. That was where it was sitting when I saved the VI, so you may have to look for it with a different monitor arrangement.

Lynn

[Bob_Schor]

This is fun!  Lynn's method gives the size of the "usable" part of the Panel.  If you want to get the "Usable Monitor Size" (which I interpret "How much space is on the monitor that I can use for my LabVIEW display, which should be the entire monitor minus the Task Bar, if it is hogging space ..."), Panel Bounds doesn't give it to you.  However, if your VI is running Maximized, and you ask for Windows Bounds, it almost gives it to you.  On my machine, where the display is 1280 x 1024, I get (-8. 1288) for Left/Right, and (-8, 1032) for Top/Bottom (if there is no Task Bar -- bottom becomes 992 if the Task Bar is present on the bottom).

I'm puzzled by the 8-pixel "invisible border" that seems to be outside of Display Space, but I suppose I could always "make an adjustment".  I should note that this code works for the Task Bar on the Secondary Monitor as long as the "measuring VI" runs from the Secondary Monitor.

BS

[Hooovahh]

All good information.  Personally I don't mind a little platform dependency when it makes life easier.  Especially when it comes to Windows environments.  In 11+ years I have never once written any LabVIEW code in Linux or Mac.  Heck I've never even seen a Mac in a work environment in my career, and have just seen my first Linux box being used at work in the last month or so.  In the field I'm in .Net being on the deployment machine is a given, so I can take advantage of that.  For those that can't, or are conserned, it looks like there are alternatives.

Oh and I think the 8 pixel border is probably an OS thing.  If you change the style of the OS (like set to Classic Windows) I'm betting the border size changes.

[BowenM]

I'm a bit late to this party, but...

I was working on a popup keyboard for a touch screen monitor awhile back that would jump to where the control was based on a Mouse Down event. Here are the VIs that would detect where the control was, and move the popup VI to that control while staying in bounds of the monitor.  It sounds very close to what you want to do.

Edit:  to be clear this doesn't get the "usable" size and uses the LV native, but the logic of where to place the window is already done which I thought you might find useful

[Bob_Schor]

---

@Hooovahh wrote:

Oh and I think the 8 pixel border is probably an OS thing.  If you change the style of the OS (like set to Classic Windows) I'm betting the border size changes.

---

Sorry, Hooovahh, there's a vacuum between my ears!  What is the "Style of the OS"?  I'm certain that Windows 8.1/Metro isn't "Classic Windows" -- is this Windows 3?  Win 95?  Win 2K?  (Better not be Vista ...).  Can you change the Style without changing the OS?

Bob (Always Eager to Learn) Schor

[JÞB]

---

@Hooovahh wrote:

All good information.  Personally I don't mind a little platform dependency when it makes life easier.  Especially when it comes to Windows environments.  In 11+ years I have never once written any LabVIEW code in Linux or Mac.  Heck I've never even seen a Mac in a work environment in my career, and have just seen my first Linux box being used at work in the last month or so.  In the field I'm in .Net being on the deployment machine is a given, so I can take advantage of that.  For those that can't, or are conserned, it looks like there are alternatives.

Oh and I think the 8 pixel border is probably an OS thing.  If you change the style of the OS (like set to Classic Windows) I'm betting the border size changes.

he Unix guy

---

Two side notes:

Nope never seen a MAC in a work enviornment (Lots of Unix, though! we often used a homonym for those programmers- I doubt the spell checker will allow a Unix homonym starting with the vowel "E")  Does any Fortune 500 company, other than Apple, use Macs on the average Joe's desktop?

Windows Themes and multi-pixel boarders that are not "usable"- Yeah, that is sub-optimal. Microsoft probably has a internal notice about that bug but, I doubt it will ever be fixed! (really, its only "Cosmetic" any SW developer that notices it can adjust a few pixels.) I Hate that mentalality! it requires developers to code for broken properties and makes it nearly impossible to fix the properties without busting code designed to work around the flaws

[Bob_Schor]

Thanks, Jeff -- I didn't think about Windows Themes.  I just tried Windows Classic, as Hooovahh suggested, and he is (partly) right -- the "overage" doesn't go to zero, but it does go to 4.  I guess this is just an example of "Microsoft Magic".  You can probably be really clever and figure out a scheme using "Mix and Match" to determine just what this border is (subtract App Display property Primary Workspace from VI Front Panel Window property Window Bounds, after the VI has been Maximized in the Primary Window).

To my shock and horror, that "solution" of mine actually works!  When I did that with the Classic Windows Theme, I got -4 for Left and Top, and 4 for Right and Bottom (with and without a Visible Taskbar), while using my "usual" Theme, the numbers were -8 and 8.

Bob (More Fun) Schor

[Hooovahh]

Yup sorry, sometimes terms fail me.  I meant things like the Aero Theme adding that border.  I couldn't remember the name, but I see now they have a Windows 7 Basic, and Windows Classic which looks like Windows 7, and Windows 3.x or Windows 95-ish.

[AndyRR]

I'm using an older version of LabVIEW (2010 SP1) so I couldn't copy paste the code. I tried to create create the Screen constructor but couldn't do that because the .NET Constructor prompt claims there are no public constructors for the Screen class. What might be the problem here? Thanks for any help in advance.

Documentation of the Screen class behind this link:

https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.screen?redirectedfrom=MSDN&view=net...