Front Panel State

[MartinPeeker]

Hi all!

I'm unable to set the front panel state property to maximized or minimized using 2010 and 8.6 on Ubuntu. Has anyone found a way to do this? Does it work on other distributions?

//Martin

[Adam Kemp]

Hi all!

I'm unable to set the front panel state property to maximized or minimized using 2010 and 8.6 on Ubuntu. Has anyone found a way to do this? Does it work on other distributions?

//Martin

I tested this just now with LabVIEW 2010 on Ubuntu 10.04, and it worked fine. Are you sure you don't have "Allow user to minimize window" unchecked in the VI's Properties? Note that this is the default for the "Dialog" appearance. You can check the current state by clicking the "Customize" button in the Window Appearance part of the VI Properties dialog.

[MartinPeeker]

GuiBehaviour.viHi Adam!

Of course, you're right. The user was not allowed to resize the window.

However, I still have problems. What I want to do is maximize my window and making it not resizable. However, it seems that if I maximize the window in all ways possible and sets rezisable and minimizable to false, I get a window that is as big as the screen but not maximized, it is still movable. It is also minimizable.

If I let the window be resizable, it does become maximized. Now an ugly workaround would be to maximize the window whenever the resize event triggers. This only works once though, and I can't really figure out why.

Just saving the vi in a maximized state or setting run-time position to maximized won't help either, due to this cross-post.

Attaching my lab code for this.

Much obliged

//Martin

Edit: I seems that making the window not resizable breaks the maximized state and that disallowing minimize doesn't work at all.

Edited January 13, 2011 by MartinPeeker

[Adam Kemp]

Maximized implies resizable. That's just how the window managers work. It sounds like what you want is something to be full screen. To do that you need a combination of multiple settings: disable resizing, hide the title bar (which appears to also hide the border), hide the toolbar (or not, maybe you want that), then set the panel bounds to be the size of the screen. Make sure to reset all of that when your VI is stopping or it could get quite annoying to work with. When I experimented with this it looked like maybe LabVIEW wasn't accounting for the invisible border when I set the panel bounds, so you may need to account for that. You also may want to hide the scrollbars while running (that can be set directly from the front panel).

[ShaunR]

Maximized implies resizable.

Errrrm

If you maximize internet explorer using the Maximize/restore button you can't resize it

[Adam Kemp]

Sure you can. Just unmaximize it. That's a resize. You can only be in a maximized state if your window is resizable because you can't get into a maximized state without maximizing, and maximizing is itself an act of resizing. That's just the way Windows and Linux (and presumably OS X) work, and at the very least that's the way LabVIEW works.

[ShaunR]

Sure you can. Just unmaximize it. That's a resize. You can only be in a maximized state if your window is resizable because you can't get into a maximized state without maximizing, and maximizing is itself an act of resizing. That's just the way Windows and Linux (and presumably OS X) work, and at the very least that's the way LabVIEW works.

Hmm.

Whaaaat?

The point I was making (don't know id you were answering it or not...lol) Was that when maximized, there are no grab-handles so you cannot grab a border and resize a window You must first "restore" it then you get your handles back and can resize it..

[Adam Kemp]

That's true, but my point is that "resizable" applies to more than just whether or not there are resize handles. On OS X there is no such thing as "maximized" in the sense of not having borders. That concept just doesn't exist. Also, in Windows 7 you can grab a title bar from a maximized window and drag it somewhere else to unmaximize and then move it. There's no such thing as "maximized and not umaximizable", and If the size can change then it is resizable. Maximizing and unmaximizing changes the size, therefore if a window is maximizable it must be resizable. Like I said, this is just how it works. You can't be "maximized" if you're not resizable. The best you can do is try the steps I listed above.

[ShaunR]

That's true, but my point is that "resizable" applies to more than just whether or not there are resize handles. On OS X there is no such thing as "maximized" in the sense of not having borders. That concept just doesn't exist. Also, in Windows 7 you can grab a title bar from a maximized window and drag it somewhere else to unmaximize and then move it. There's no such thing as "maximized and not umaximizable", and If the size can change then it is resizable. Maximizing and unmaximizing changes the size, therefore if a window is maximizable it must be resizable. Like I said, this is just how it works. You can't be "maximized" if you're not resizable. The best you can do is try the steps I listed above.

Indeed. If it s maximisable then it is resizeable. But if it is maximised. it might not be resizable. The behaviour you are describing in Windows 7 is a feature of Aero that can be turned off or may not be available on some systems (and doesn't doesn't exist in XP, Vista and probably not in linux either)

I think what the OP is seeing is this.......

Create a new VI and put something in it so that it will run continuously.

Uncheck the VI properties "Allow User To Minimise Window" and Allow "User To Resize Window"

Turn off the Aero Snap

Maximise the VI.

Run the VI.

You should now have a full screen window that you cannot resize or move. and there are no minimise and no restore/maximise buttons. So far so good.

Double click on the title-bar.

It restores and now you are stuck with a non-resizeable, non-maximized (able) window. Well in 2009 at least.

[MartinPeeker]

Maximized implies resizable. That's just how the window managers work. It sounds like what you want is something to be full screen. To do that you need a combination of multiple settings: disable resizing, hide the title bar (which appears to also hide the border), hide the toolbar (or not, maybe you want that), then set the panel bounds to be the size of the screen. Make sure to reset all of that when your VI is stopping or it could get quite annoying to work with. When I experimented with this it looked like maybe LabVIEW wasn't accounting for the invisible border when I set the panel bounds, so you may need to account for that. You also may want to hide the scrollbars while running (that can be set directly from the front panel).

Hi Adam!

Thanks for your response!

I've been thinking of your solution, and sure, it is one way of doing it, but it doesn't get me all the way.

What I try to accomplish is:

A window that fills the screen except the toolbar (this can be done using the Application.Display.PrimaryWorkspace property together with given size for the toolbar)

A window that is not movable (as it is when it is truly maximized)

A window that is not minimizable.

A window that cannot be resized.

A title bar

It seems I can't get it all:

Maximize, and it will allow me to minimize

Fill the screen using window size, and it will be movable using the title bar.

Also, If is set run-time position to maximized, it does not become maximized. The size seems to close to right, but the window is not positioned at (0.0) and it is movable.

If I save the vi as maximized and choose unchanged as run-time position, the window is properly maximized (not movable)in edit mode, while in run mode it is movable. Not allowing minimize has no effect.

Your right that it most probably has to do with the window manager, but I don't think that is the sole culprit.

If I save my vi maximized, not minimizable and open when called, then run it as a sub-vi it will be too wide, too high and not placed at (0.0). But it will not be minimizable.

If i run it as a top-vi it will almost have the right size, have the right width except for the right border, but it will be minimizable.

I believe there is no good solution to my problem, and since I'm not on a supported distribution I can't complain too much, but if this behaviour exist on supported distributions I would call it a bug.

BTW, I have never worked with OS X, but surely you must be able to configure a window to fill the screen and not be movable? (And then, hopefully, disallowing any resizing or minimizing of any sort).

ShaunR, thanks for entering the discussion. Double-clicking the title bar does not change the size for me (2010 on Ubuntu).

//Martin

[Adam Kemp]

Uncheck the VI properties "Allow User To Minimise Window" and Allow "User To Resize Window"

Maximise the VI.

Run the VI.

...

Double click on the title-bar.

It restores and now you are stuck with a non-resizeable.

That least part is a contradiction, though. A "restore" is a resize. You can't say it's not resizable if you are able to "restore" it. That changes the window's size, therefore it is resizable.

The fact that you can get into that state is a result of the fact that we treat non-running VIs differently. When you maximized the window it was resizable. It's a bug that when you run the VI and resizing is disabled we don't immediately unmaximize it. That's just a bug, though. What you described after you unmaximize is the correct behavior. You should not be able to do anything to a non-resizable window to change its size, including maximize or unmaximize, and as I said before, you can't have a "maximized" window which can't be unmaximized. Therefore maximized and non-resizable windows are a contradiction.

What I try to accomplish is:

A window that fills the screen except the toolbar (this can be done using the Application.Display.PrimaryWorkspace property together with given size for the toolbar)

A window that is not movable (as it is when it is truly maximized)

A window that is not minimizable.

A window that cannot be resized.

A title bar

This can't be done. As I said, that's a contradiction. You can't have a "maximized" window that is not resizable. It's just not allowed. The only way to disable minimizing unmaximizing is to disable resizing, and disabling resizing means you can't maximize to begin with.

I have to ask, what value is the title bar if you can't minimize, unmaximize, etc.? Why do you want the title bar visible? If you hide that you can't move it. Problem solved. I think you're making it harder just to show a useless title bar.

I believe there is no good solution to my problem, and since I'm not on a supported distribution I can't complain too much, but if this behaviour exist on supported distributions I would call it a bug.

This is not a bug. It is the expected behavior.

BTW, I have never worked with OS X, but surely you must be able to configure a window to fill the screen and not be movable? (And then, hopefully, disallowing any resizing or minimizing of any sort).

Not in teh way you have described. The presence of a title bar implies that you can move it. The ability to "maximize" (which in OS X means make larger, not necessarily fill the screen, and it doesn't ever disable resizing of any kind) implies that you can resize the window to begin with. This is the platform where that contradiction is most apparent because "maximize" is truly just a resize. It's equivalent to manually moving and stretching the window to fill the screen, thus is can't be done if you disable resizing.

The only way to get a full-screen, non-resizable, non-movable window is to disable resizing, hide the title bar, and set the window size to be the full size of the screen.

[ShaunR]

. That's just a bug,

Does it have a CAR?

[MartinPeeker]

Hi Adam!

Thanks for all your help. I see your point now with maximized windows needing to be resizable in order to let them be minimized. I guess there is a good reason for this, having a window as opposed to full screen implies that there may be other windows, hence you are not allowed to let your window fill the screen without possibility to minimize it as this would make it impossible to see other windows.

I have to ask, what value is the title bar if you can't minimize, unmaximize, etc.? Why do you want the title bar visible? If you hide that you can't move it. Problem solved. I think you're making it harder just to show a useless title bar.

The reason i want the title bar is that I like the standardized look. I need a title in some way and that is the natural place for it. It also gives an intuitive placement of the menus as I find menus without title bar look a bit weird.

//Martin

[Adam Kemp]

Does it have a CAR?

CAR #281328.