Mads

Great, thanks for the effort! It is good to see that it required the trick of using a button that already had an extra part to replace...if it had been straightforward it would have been more irritating to have missed it... M

The buttons from OpenG Builder can be used as a template to create different system buttons with icons, however how did they make it in the first place? If you go into customization mode and right click on the icon you see that it is an item on its own with different icons for 4 different states...just like a button (as I first implied, although as separate controls), but it is not -because you cannot have a second control within the control, it's something else. Is this just some special button control from NI that was edited for Open G Builder, or can it be made from "scratch"?

Yes, but how do you paste into one of the states without having to replace that state completely (loosing the system adaptive part of it)?

Creating custom buttons has never been a problem - as others have described here its just a matter of importing images to replace the different states of the button...however that replaces the whole button image, what we want to accomplish here is to have a system button "background" that will automatically adjust its appearance to the system it is run on....BUT with an icon on it. I cannot see that anyone has described how to do that without using two buttons - one system and one customized. (If you just go into edit mode on a system control and paste the icon it will become a blind spot. ). It would be great if there was a more elegant way to do it. Mads

The VI Package Manager is off course made in LabVIEW so it is possible... I could be dead wrong, but my guess is that there are two buttons there - one system style to make its color, highlighting etc. work as it should and then a second button that is just the icon...The latter button has had its entire graphics replaced by graphics with transparent edges. Then there is some event handling to make the system button go down together with the icon button when you press it...and vice versa. You can edit a system button and put graphics on top of it, however for some stupid reason the graphics will then act as a blind spot for the button - clicking on it will not give you any response. Mads

The TCP functions run in parallell. We have servers made in LV that handle simultaneous uploads and downloads from hundreds of clients, the communication flows as it should. If there was a need to set the VI to reentrant or it was impossible to allow parallell execution I think NI would either have made it into a subVI you could edit or they would have documented the lacking possibility of parallell execution (if not you would have seen tons of messages discussing it as a bug:-)). Mads

That's great, thanks! Why do they hide all the useful stuff....Scripting is great but not released. Inlining is there but why cannot they make it available as a VI option:-( Mads

The reasons to use sub-VIs have already been covered, however there is a downside to using sub-VIs that should be mentioned. If the code is going to be called thousands of times the overhead in calling a subVI will slow down the execution dramatically so sometimes it is just not a good idea. It would still be much better if you could organize the code in a subVI in the programming development and then flatten the code during compiling, that way you could get neat looking code, reuse etc, but without the speed penalty. I suggested a "flatten when compiled" feature to NI a couple of years ago (could be a subVI option, right click on it and set it to flatten...), however I have not seen any hint of it being implemented. Mads

I was a bit surprised to see this reply because I have always thought LabVIEW executables would terminate immediately if they do not have any front panels open...and when I tried this just now that still seems to be the case, however I am using LV 7.1.1 here so perhaps this works in LV8 or there is some detail I have overlooked? I deactivated all options in the window appearance option window and the first thing I run is the VI close method, and voila - the application does no longer run. Regards, Mads

It looks very useful. It would be nice if the open VI was able to automatically create a new database if the path it is given does not exist (you could have a create if it not exists input).

That would be a great feature, and it should have been available. I sent in a suggestion to NI a long time ago to at least stop including the cluster frame in the tab navigation list, for the user of an application built in LV there is never, ever, a reson to highlight what is essensially a programmer's tool. As far as the GUI goes the cluster should not even exist.

Well that's the thing you see - you can (obviously) and you should be able to (off course, it's 2005 after all!). It might be there in LV7 as well. I tried recreating the problem in 7.1.1 and could not get it to happen, maybe it is possible to get the same problem there, but at least it was more difficult...;-) No matter what angle you see it from it is still a bug. I've made the same mistake myself when doing rescaling by code, if you use the original size of the controls and the front panel as fixed references to calculate your scaling factor you can avoid the problem.

Controls are scaled "live" in LV8, they do not wait until you have released the window handle (the grab handle is not there anymore by the way...consistent with the OS so that's good). The algorithm behind seems to have a bug though...just widen the attached VI front panel and you'll see that the controls will expand too much to the right and move outside the visible front panel...This did not happen in LV7.1. Download File:post-1777-1130421408.vi

Followup: The INI keys are the same in LV8 and the bug also applies to the development environment. If you change the font options the menus and the _ prefix will no longer work properly.

Found it! The bug occurs if you override the app and system font in the application INI file. Just put appFont=""Tahoma" 13" systemFont=""Tahoma" 13" in the INI file and you will see the menus garble up in the built application. I have not yet looked to see if these keys have changed, been replaced or removed from LV8(?), it is still a bug in my eyes but perhaps just a backwards compatibility bug...(?) I have attached an example. Removing the last two keys in the .ini file will as you can see remove the problem. Download File:post-1777-1129978050.zip

This actually seems to be two bugs: One is the fact that _ prefixes are interpreted incorrectly and secondly there is no separation between menu items, they are piled together regardless of the use of _ prefixes...Ugly one! Makes menus in built applications useless unless you only have one menu...

Downloaded and activated LV8 and converted one of our projects from 7.1.1. A bit of a struggle to get all the dynamically linked VIs to refer to the right sub-VIs now that it supports "name spaces", and it seems a bit strange to add VIs directly from disk instead of selecting them from the project, HOWEVER... I came across something that looks like a bug, namely how built applications handle top level menu items that have a _ prefix in their name to allow Alt+Letter navigation. It works as it should in the development environment, but when you build the application the menus end up in a pile and the _ prefix has become a line above the first letter instead. Look at the attached illustration. Is this something anyone else have seen or can reproduce?

I can create event and case structures using scripting and put them into a loop etc., however I need to also make and link a number of frames, has anyone successfully done that using scripting? Adding a frame is easy enough, but to link it to an event or selector value seems to be more difficult. For a case structure there is a selector strings property, but that is read only...It seems a bit strange that you can make all the code, except give the frames their names / event link...so I hope it is doable. Alternatively: The end goal is to make a central GUI handler based on an event structure that can react to clicks on a large number of script-created buttons (hundreds, perhaps thousands, spread across different VIs). The event structure should fire when any of the buttons are clicked and identify them and perform the appropriate action based on the label of the button...Creating one frame linked to a mouse down for all the buttons would be one way, separate frames for each event a second way, but the linking must be automated as well...