Lock front panel with has titel bar?

How can I lock a front panel that has a title bar?
I do not want that the user
- close the window --> ok, vi-property
- resize the Window --> ok, vi-property
- minimize the window --> ok, vi-property
but:
I also want, that the user can't move the window using the titel bar
I do not want to poll permanently the windows-position.
Any idea?

Hello zav,
via vi->property node you can also set the window size. So switch of
closing/resizing/minimizing in the vi properties dialog and do the rest
in a small while loop parallel to your main program (permanently set
the window size to the size of the screen).
Attached is a picture of a sub-vi calculating the window position
regarding to screen size. The output is wired to a property node
'Frontpanel Window.Window Bounds'. Hope this helps...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Attachments:
WindowSize.png ‏4 KB

Similar Messages

Unexpected effect of Lock Front Panel in Event Structure

I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.
When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.
It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.
Attachments:
Sample.png ‏7 KB

I would say what you see is expected behavior, even though it's a bit complicated.
The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.
When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.
From the LV help:
By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked.
Note If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.

Disable/Lock Front Panel Programmatically

Hello
I have a huge project with a bunch of boolean controls. Each boolean triggers an event. So when an event is triggered, I disable all other booleans to avoid any event lock up.
There are cases where I have to disable ALL the boolean, for ex. when saving, I disable all controls till a report is generated. Is there anyway I can lock or disable the front panel programmatically rather than use property nodes to disable them ? I am losing a lot of my real estate and VI becomes really huge (1.41 MB so far, just the top level )
Thanks !!
Kudos always welcome for helpful posts

Maximus00, like you, I have a huge VI (complex UI with controls/indicators), It is now 2.5 MB in LabView 8.20 (in 6.1, it is about 5mb). I'm looking for the same thing, that is how to disable the Event Structure "locking front panel". Currently, I disable all 50 events for this feature, but this is cumbersome, tedious, and should be a better way. I came across your post and wish LV had a way to programattically disable it, via a property node. The VI I am working is large, and will most likely be used be maintained by multiple developers so it is critical that there is some way to inhibit the "locking front panel", anytime they add or edit an event. It is definitely NOT a good thing to have the VI lock up! By Programmatically disabling all of the event structure's locking front panel, this would protect the VI code from locking up, if a new developer is unfamiliar with the code.
If anyone knows a way to Disable/Lock Front Panel Programmatically let us know!!
-crazycliffy
- crazycliffy

Lock front panel until the event case for this event completes

A Dynamic Event is a filtered event? Is this why "Lock front panel until the event case for this event completes" is not shown on Edit Event window dialog? I use Dynamic Event so I can subvi the event structure.
I need stop my app from locking the FP whenever the user double clicks on the numerical array value (<-- the FP freezes the mouse and renders it useless) and stops the value from ever being changed. This event is registered for Value Change (not mouse up or down) and I get a locked mouse. As yet in the UI, no value changed occurs but I get a locked mouse. A LV bug?
Trying to KISS, I can see this fixing this by moving ONLY the value change event to the top level VI instead of a dynamic registered event in a subVI. This will give me the option to NOT "Lock front panel until the event case for this event completes" .
Solved!
Go to Solution.

richjoh wrote:
Thx, Ben that fixed the problem when I unchecked "Lock panel...".
So it appears LV locks the panel during runtime once the Dynamic Reg Events is on BD and it doesn't matter if your case to handle the Reg Events is created or NOT... interesting. That's why my mouse persisted to "freeze up" although I deleted the case for my FP array.
Its situation like what you described that has given me many insights into how LV actually works. In one of my bbuggy VI's I found that a class wire can run a million miles through multiple sub-VI queues etc but the data itself is only touched when it has to be touched. in my case it was a crash while trying to write bogus class dat to a TDMS file.
I am glad you are back on course.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Same object size (front panel) with different screen resolution

Hi everybody,
I realised an application, and I try to instal it on various computer. The probleme is that they haven't the same screen resolution, so the front panel is not the same on each computer. It is possible to build an application which have the same front panel with different screen resolution ?
Kriss.

Hi Krisss,
switch off any "adapt to screen resolution" switches in the VI properties...
You should also define "same front panel" and "same object size"! Do you mean the same pixel size or size in mm or size in percent of screen?
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Remote front panel with labview 8.6 executable

I am trying to create a remote front panel of my application, built in an executable using Labview 8.6. I want to run that application on a target machine (not the one used for developing the project) and view and control the front panel of the VI from a web browser on another computer.
I have followed these steps:
How can I use remote front panels with Labview Executables?
But when I finally open the web browser and navigate to the URL I obtain that the page cannot be found.
I have my Labview project created and I have built a web page using Web publishing tool. I have saved it in my Labview 8.6/www directory and added it to the project. I have built my executable including HTML file and copied all the obtained folders to the target PC.
Then, I have modified the .ini file like in the step 7, but when I arrive to the step 8 I don't know what to do. Which niwebserver.conf should I modify? The one localized at Labview 8.6 directory of the target machine? Or the one that is created in the directory where I have copied the executable when I run the executable?
In the DocumentRoot tag I have to replace the default Labview/www with the location of my HTML file. Should I use quotation marks or no?
Have you got any ideas of what is happening?
Thanks!

Ok, but when I create the executable, in the folder where the application.exe and .ini are there isn't a file called niwebserver.conf. When I run the application a file with this name appear in the directory (the one I include), but it hasn't the section Directives that apply to the default server as in the manual.
What I have done is to copy the niwebserver.conf file ubicated in the Labview 8.6 of the target machine in the same directory of the executable but it doesn´t work...
niwebserver.conf
ServerRoot "."
ErrorLog "./logs/error.log"
LogLevel 3
ServerName default
DocumentRoot "./../../www"
Listen 80
ThreadLimit 10
TypesConfig mime.types
DirectoryIndex index.html
LoadModulePath "./modules" "./LVModules" "./.."
LoadModule LVAuth lvauthmodule
LoadModule LVSnapshot lvsnapshotmodule
LoadModule LVRFP lvrfpmodule
LoadModule LvExec ws_runtime
LoadModule dir libdirModule
LoadModule copy libcopyModule
AddHandler LVAuthHandler
AddHandler LVSnapshotHandler .snap
AddHandler LVRFPHandler
AddHandler LvExec
AddHandler dirHandler
AddHandler copyHandler
CustomLog "./logs/access.log" "%h %l %u %t \"%r\" %>s %b"
KeepAlive on
KeepAliveTimeout 60
Timeout 60

Programmatically Open a Remote Front Panel with Panel Open Method

Hi,
I am trying to open the front panel of the VI on my cRIO-9024 through a remote computer. Currently, I am able to run the VI with no problems with the RUN VI method; however, when I try to open the front panel, I receive "Error 1043 - This property or method is not supported in this version of LabVIEW" or the Front Panel is simply not visible. My cRIO is configured to allow TCP/IP protocol, The VI is visible, and I have made my project into a source distribution on my cRIO.
Any help or suggestions regarding this problem would be great. I am very new to LabVIEW.
I have attached a screenshot of my block diagram and project.
Thanks,
Jake
Attachments:
Block_Diagram.PNG ‏12 KB

Project Img
Attachments:
MyProject.png ‏15 KB
MyProject.png ‏15 KB

I want to save an image of the front panel, (with data), after every VI run

When I try to copy the front panel (using a select all), and paist to paint, all the data in the graphs show up as they did after the last run, but the data in the charts dissapear. The chart itself is copied but the data is not. Any ideas on how to solve this?
Thanks,
Brian
Attachments:
Brians_graph_compilation2.vi ‏1363 KB

This Knowledgebase also has some information on programatically saving VI images
http://digital.ni.com/public.nsf/websearch/942DAA35C7B35616862565FE005F713F?OpenDocument
(KB 197BB7VJ if the link doesn't work).
Note that you don't have to put the code in the VI you are running in order to save it to a file, so you don't actually have to modify your VI. You can just run a seperate VI that uses the VI name from the first one (I've attached a VI which could either be run standalone or used as a SubVI, as well as an example of using it as a SubVI).
If you don't want to do it programatically you could just hit the print screen button on your keyboard and then paste it into paint and crop off the extra windows stuff.
Attachments:
CreateVIJPEG.vi ‏34 KB
ImageExample.vi ‏24 KB

Using a "menu ring" feature on the front panel with event structures

hello - right now i have many event cases controlled by many "ok buttons". i would like to use a menu ring on the front panel to save space from all those buttons, but i don't see how it will work with all the individual event cases. currently each event is tied to a single button, and the menu ring acts as one thing on the block diagram so i can't tie an event to a choice in the menu. any suggestions? thanks....

Alternativley, you could use an enum control instead of a menu ring. It will name the cases according to the selection automatically.
If you want to use a menu ring and strings, you could do something like in this image.
Message Edited by altenbach on 02-09-2006 01:43 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
RingText.png ‏3 KB

Publishing front panels with web server

Hello,
I'm working with LabView 7.1 and trying to publish a front panel by means of the web server.
The problem is that I'm only able to connect to the VI through the internet when both , the host and the remote are networked.
When I try with computers outside that network the browser doesn't find the webpage.
Thank you for your help
Lian

You need to know:
The public IP of your router.
The private IP of your LabVIEW server.
The port used by your server.
First you need to forward the port on your router. Basically, you need to tell the router that incoming NEW connections to a certain port of the public IP of the router should get forwarded your server. (Without forwarding, the router only works for outgoing connections). Once the port is forwarded, clients located on the outside need to connect to the public IP of your router.
Possible complications:
Your ISP might block certain incoming ports for security reasons. In this case you can configure a different port for the server.
With some routers you will not be able to connect to your server (for testing) with a client located on the same LAN via the public IP of the router. Only routers that incorporate a loopback proxy support this. What is the brand and model of your router?
Good luck!
LabVIEW Champion . Do more with less code and in less time .

Hiding front panel with built applications

I've seen and used the techniques to run a VI with a hidden front panel. I have the VI open a reference to itself and it works as expected. However when I build my code into an application, it no longer works. Watching Task Manager I see the application quit when the panel becomes hidden. I've even tried building the window-less.zip example I downloaded from the NI website. It worked in VI form but not in EXE form. Anyone have any suggestions?
Andy Brown
Averna

Andy,
I ran into this problem back in LabVIEW 5.1 when I was developing a game in LabVIEW. I had an introductory screen that allowed the user to run the tutorial or play the game, and upon selection I hid the introductory screen and displayed the panel of the appropriate subVI (tutorial or game). Unfortunately when I built an executable, it would end once I chose to run a subVI, and I later found out that this is because closing the front panel of an executable essentially closes its reference. My workaround was to use LabVIEW 6i and the new tab control to keep all of my front panel operations in the same VI, and programmatically switch between the tabs in order to display different screens (like tutorial, enter info screens, the actual game, etc.)
I hope this
suggestion helps. There may be a way to bypass the problem with closing EXEs once their front panels are gone, but I do not know of one.
Good luck with your application, and have a pleasant day.
Sincerely,
Darren Nattinger
Applications Engineer
National Instruments
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Audio Front Panel with MSI

1.Product Type: Motherboard MSI G965M MS-7241 with integrated Realtek audio and updated driver for Windows Vista - 6.0.1.5331
2.BIOS version: AM v. 1.1, 2006-10-23
3.External VGA Type: NVIDIA GeForce 7600GS
4.CPU Type: Intel Core Duo 6400
5.Memory Type: Dual Channel 2GB
6.Power Supply Type: 400W
7.Operating System: Windows Vista
8.Problem Description: Front panel audio connectors 3,5 mm plugs are not operating regardless they are connected to JAUD1 port. Plugging with the headset with microphone doesn't gives any effect - they are unvisible by the system.

Does the case support HD Audio"Azalia"?
Have you tried to disable the front panel jack detection under analog connection settings (click on the wrench) in the Realtek HD Manager?
This thread may or may not help: https://forum-en.msi.com/index.php?topic=105631.0

Remote front panel with viewing mode in monitor jams if two browser connects

I made a exe with the vi attached, with the web publishing viewing mode set to monitor every 1s.
I copy all the executables and generated files to a target computer. The target computer is 4 CPU 2Ghz, 1Gb RAM, Windows 2000.
If I open a client web browser connection to the remote panel, everything is fine, I can see updates every 1s or so.
But if I open two client web browser connections, the display in the two web browser grinds to a halt, and the exe in the server computer slows down from 1s update to 6s update.
If shut off one client web browser, the other client browser and the exe in server go back to normal speed.
So what is the problem? How do I solve this problem? Is this problem solvable?
Attachments:
monitor4.vi ‏85 KB

Bump.

Front panel locks with event structure loop and another while loop

Hi,
Why is the front panel locking after changing the value of the "boolean switch" twice? This problem disappears if I uncheck the "lock front panel" option in the event case. However I don't understand why that is the case since the event structure loop has already finished executing.
thanks

Do you really want the event handling to stop after detecting the first event? If so then as Christian says the event structure will cause the front panel to lock. What you can do is dynamically register and unregister the events. You right click on the event structure and enable "Show Dynamic Event Terminals" Then you can programatically register and unregister events.
Here is your vi modified to do that.
Edit: Just in case - right click on the control and create a reference. When selecting the source of the event in the structure look under the dynamic section.
=====================
LabVIEW 2012
Attachments:
event structure test.vi ‏13 KB

Static VI with Visa serial functions is very slow to display front panel

THere is a delay time of about 10-20 seconds to "display" the first VI's front panel that has Visa serial functions in the source code.
All works fine after the first load but the initial delay of the front panel load makes it look like the PC could hang during this time. AFter this other VI's load immediately with no delay. I am concerned because I do not want to have to load a VI manually every time I start the APP which is the only workaround I can do at this time.
Im wondering if anyone else has seen this kind of behaviour.
I do not remember this happening until I upgraded my APP to LV7.
DEll optiplex GX260 with 500MB RAM, Win2k and using N.I PCI-232-16 card w/ LV7 now.
Attachments:
RECV_LOOP.vi ‏55 KB

I would like to resurrect this thread, as I am having the same problem. The problem stems from the VISA resource control on my front panel, because I have many COM ports registered on my system. The last suggestion from Scott B. was to "post the resulting .SPY file and I'll take a look at it". So, here is my .SPY file, and as you can see, it takes far too long. As many of these COM ports were registerd from USB converters, most of them are not actually present at this time on the system. However, even the ports that ARE present take a long time to register (i.e. COM1 is present and shows 3 seconds to register). These COM ports shown in my VISA resource do not correspond to those shown in my Device Manager, nor do they correspond to those shown in MAX under Devices and Interfaces.
I am using LV 7.0 on WinXP SP2, with VISA version 3.2.
OK, I just discovered something that mostly cured the delay. When I was getting the VISA version number just now, from MAX in the Software>NI-VISA item, there is a tab "VISA Options", and another tree structure in the middle pane. Selecting "General Settings>Aliases", there was a list of the old COM ports, so I cleared this list and then re-started MAX, checked again, and now only the COM ports shown in "Devices and Interfaces" matched this list (which still doesn't match my Device Manager, but no matter). When I re-opened the LabVIEW FP, it opened quickly, and the ports listed in the VISA resource matched those I saw in MAX.
At any rate, although I just cured the symptom, the original problem of old aliases in VISA causing unacceptable delay should be fixed by NI.
David Moerman
TruView Technology Integration Ltd.
P.S. the message poster didn't allow my to post a *.spy extension, so here is the *.zip of it.
Attachments:
Capture.zip ‏2 KB

Lock front panel with has titel bar?

Similar Messages

Maybe you are looking for