RagingGoblin

Yuri33, Thanks for you answer and you suggestion. As you say an 'ugly' solution, but appearantly we have to live with this, I will adopt your strategy.

QUOTE(Aitor Solar @ Jan 17 2008, 05:12 AM) This is the error I get: Error 1055 To More Specific Class in invoke_all_xcontrol_indicators.vi->test_publ.vi I use version 8.20, on the NI board I saw the same post: http://forums.ni.com/ni/board/message?boar...hread.id=287670 In the upgrade notes from version 6.02: The To More Specific Class function used with a control reference as the target class input no longer returns “error 1055” in built applications.

Hi, I made a vi that invokes a property on all xcontrols on the front panel. In order to get a reference to all controls I use a property node Controls[] and use the "to more specific class" function to get a reference to my specific xcontrol. This goes well within labview, but after building an executable of this, an error is returned by this function. How can I cast this reference to my specific xcontrol? thanks.

Well, now I do feel stupid. Though I must say on this system (Linux running on VMware) the behaviour is really not what I would expect. Not dubble click, no click many times, but click... count to three ... click. Thanks for your help.

I am making a fool out of myself here, I know, but I just cannot get it done. In your movie it looks as if you are switching to run mode before editing a line, what are you doing exactly? Or has it something to do with me working on Linux?

Yes you can edit the items on the listbox inside the xcontrol on the facade. But I want to edit the items on the listbox inside the vi. Try to edit items in Untitled 1.vi, see attachement. Thanks

Hai, When I place a listbox on a VI frontpanel it is possible to edit the itemnames (the cells) by dubbleclick and start typing. However, when I place a listbox on the facade of a xcontrol en put this xcontrol on a VI frontpanel it is not possible to edit the items in this fashion. I have tried to get this behaviour by editing the event edit cells, but this event never happens. The listbox on the facade is set to editable cells (right click Editable cells). Any suggestions to this? Thanks

Wolfram, would love to see your solution, but I only have 7.1. Can you send a picture?

Hey Guys, I am still wondering what causes can stop a program which front panel state is set to hidden. Because every night around twelve it stops, but keeps running if the front panel is open. Guess I have to ask my system manager what is happening at night. Eaolson, yes you

I use a toolkit from Karsten van Zwol, LabVIEW_Tray_Icon.lbb. Got it from here: http://forums.ni.com/ni/board/message?boar...essage.id=95141 This is used to create the icon. To close the frontpanel I use a property node to set the Front panel state to hidden (see above). Download File:post-4151-1161675844.llb

The other cases are mostly not that importand. They only change the mousepointer into a hand and backward if you hover over a clickable item. Two cases handle the events if you click on the icon in the system tray. The timeout doesn't do anything either, just going on with the next loop. Crelf, yes I am pretty sure, because if I only minimize the app, it runs for days.

As stated above I want to run an application in the background. According to NI this is possible: http://digital.ni.com/public.nsf/3efedde43...67?OpenDocument I used this technique. If anyone clicks the black x to close the program it will run in the background, but is accessible through an icon in the system tray. This works fine, but after a couple of hours the program stops completely. Can anyone tell me why this could be?

Is it possible to remove the menu entirely? Window appearance -> show menu takes effect after launch, I don

http://forums.lavag.org/index.php?showtopi...p;hl=tray++icon http://forums.ni.com/ni/board/message?boar...uireLogin=False http://digital.ni.com/public.nsf/allkb/1bb...67?OpenDocument Good luck !

Read LabVIEW Application Builder User Guide, I found this out recently myself, so I told myself RTFM There are some caveats: If the VI loads other VIs dynamically using the VI Server or Call By Reference Nodes, make sure the application or shared library creates the paths for the VIs correctly. When you include the dynamically loaded VIs in the application or shared library, the paths to the VIs change. For example, if you build foo.vi into an application, its pathis C:\..\Application.exe\foo.vi, where C:\..\Application.exe represents the path to the application and its filename. Another trick: Help -> explain error