modified app builder for full screen front panels

[_addi_]

In my mind the behavior below is more a bug than a feature request. But I was asked by the NI engineer to notify this here so that the chance is higher that it will be implemented (fixed).

I wanted a fixed full screen front panel of the monitor resolution (1280x1024) without any 'surroundings'.

Therefore I used in VI properties no title bar, no menu bar, no symbol bar, no close, ...
and 'minimum window size X 1280 Y 1024' together with 'no change of window size'.  

What is generated by the app builder is not what I expected:



Surprisingly one pixel less in window size improved the appearance but yet poor boundary (still something wrong):



When I tried with larger monitor resolution it can be seen that the front panel always wants to be larger than predetermined:

Conclusion of that: The app builder adds the pixel height of the hidden bars (46 pixel) to the Y value. The resulting app then is 1280x1070 and doesn't fit into a 1280x1024 monitor. What can be seen are scaling effects. So my 'feature request' is, that the app builder should take into account when a user selects hiding bars together with fixed front panel size.

My workaround is (LV development on monitor with larger resolution):
1. setting VI properties to X 1280 Y 1024
2. reduce the front panel window size to the limits (window then equals 1280x1024)
3. move the scrollbars so that the desired user screen can be seen
4. change VI property Y to 978 (=1024-46)
5. build the app and enjoy

[ToeCutter]

I agree it's a bug- voted anyway.

[0utlaw]

Hello _addi_,

This appears to be the same issue described in this thread:

Extra White Space from Hidden Menu Bar

http://forums.ni.com/t5/LabVIEW/Extra-White-Space-from-Hidden-Menu-Bar/m-p/2712347#M804416

The issue appears to occur only when the menu bar is set to hidden and the front panel is also sized to exactly the minimum specified in the VI properties.  As you noted, modifying the minimum panel size to less than the default panel size resolves the problem.

[PNR]

Thanks for sharing with that amout of details, it is always good to know about known issues.

Anyways, why should bugs or let's rather say malfunctions be posted as ideas? (Is it a bug if the behavior just doesn't fit expectations?)

It has been the same with one of mine: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-NULL-parameter-in-NET-Event-Callback/idi-p/26...

Most of these problems are far too complex for a voting system like the Idea Exchange in my opinion, so I wonder if such issues will ever be resolved...

[AristosQueue (NI)]

> Anyways, why should bugs or let's rather say malfunctions be

> posted as ideas? (Is it a bug if the behavior just doesn't fit expectations?)

Bugs should not be reported as ideas, but there are times when it is hard to tell the difference between "it works the way the developers expect but not the way the customer expects" and "it works in a way unexpected to both developers and users". The former is a feature request, the latter is a bug.

> too complex for a voting system like the Idea Exchange in my

> opinion, so I wonder if such issues will ever be resolved...

You are correct. The Idea Exchange serves as a clearing house for all ideas coming in from users. The Kudos provides one form of guidance for us to work on ideas. But when developers are working on a specific section of the code, they do look for ideas relevant to that section that may be addressable at the same time. Also, if enough low-kudos ideas buid up in a section of the code, they may be collectively enough to trigger working on that region.

As I keep telling people... the size of the LV R&D team is smaller than most of our users estimate. This does mean that years can pass between a good idea being suggested and a good idea being acted upon. We try our best, but LabVIEW is a broad product and we have way more users making suggestions than we have develoeprs able to work on them. But that's also why we don't just close out ideas just because they don't gather lots of kudos.

[crossrulz]

Is there a CAR to cover this issue?

[intvsteve]

Hello,

This appears to be a bug brought about by some unique circumstances. If I understand the description, the desire is to have a VI be 'full screen', with no title bar, tool bar, menu bar, or scroll bars.

When a window is maximized, Windows retains a 'restore bounds' data structure to use when the window is 'restored down' to the state prior to maximization. It appears that there are interactions between this, the run-time panel size requirements, and the transitions between edit and run time. When this VI runs, at least on my computer, the minimum size actually is vertically too large to fit on the monitor, so the VI cannot meet the conflicting criteria of being maximized *and* have the requested size. There is some sort of fault in this conflict resolution.

Please file a bug report for this.

I also have a simple workaround that should help you achieve your goal. You do not need to configure panel size in the VI Properties dialog. Instead, use this VI server code (image only) and your VI should be full screen on the primary monitor of the system upon which it runs:

If you configure the panel as indicated (no title bar, scroll bars, tool bar, menu bar), this code will size the entire VI's panel to fill the complete dimensions of the primary monitor, including the task bar.

[AristosQueue (NI)]

PNR:

intvsteve wrote:

> Please file a bug report for this.

Obviously we think we know about the issue so you filing a bug report may seem redundant. We're asking you to file the bug report in order to make sure we are talking about exactly the same issue and so that you can attach your code to demonstrate the bug to us. If you'd rather not, we can just file the bug report from this thread without your name attached to it. Please post here which option you prefer.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.