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...