ggatling

QUOTE (crelf @ Apr 8 2009, 08:50 AM)

I'm going to say this one more time: you are confusing undocumented features with experimental features. They are not the same.

I'm not confusing them at all. I'm just hijacking the thread! :ninja: I have no complaints with the inclusion of undocumented features or locked features. But enough "tested", "non-experimental" features (doumented, secret, 1337-only,...) make it into release versions with bugs, occasionally crippling ones, to give me the heebie-jeebies about each new version. Of course NI cannot wait until LabVIEW is perfected and bug free to release it. There is a balance somewhere between adding inovative new features and refactoring, debugging, or otherwise fixing existing code. I'm not sure where the Right Place is on that spectrum, if there is one, but I was making the argument that I feel like NI does not incorperate enough of the latter, especially given the fact that to get the bug fixes I must also accept the new features.

QUOTE (bsvingen @ Apr 6 2009, 03:56 AM)

...open source software allways has a "stable" branch that is fully "documented" (open) and does not contain experimental code. Any changes done there is to fix bugs. The experimental code is reserved for "nightly builds" and betas, but at least it is documented. What NI is doing is to include the experimental code in the stable branch...

Here here! I have long opposed NI's practice of adding horrible buggy code into the Latest, Greatest release together with all the bug fixes for the previous version. I feel certain NI's current release schedule is driven by a business model that does *not* center around releasing an amazingly powerful, undeniably stable software product. That being said, LabVIEW is still the best tool for my job, so I make do.

(Clearly still licking my wounds from 8.0)

I am wondering if there is a way to force an xControl to be *only* a control or *only* an indicator. Or, if this is not possible, is there an acceptable way to signal the user that the control does not have a defined behavior for one of the data directions?

I am wondering if there is a way to force an xControl to be *only* a control or *only* an indicator. Or, if this is not possible, is there an acceptable way to signal the user that the control does not have a defined behavior for one of the data directions?

I would like *everything* to have a label. I actually wouldn't mind (maybe even prefer) if everything got a comment field… similar to the caption of some front panel items. Wires, stop terminal on while loops, index terminal on loops, tunnels, shift registers... everything. I want as few free floating comments as possible. That being said, I DO want free floating comments for the front panels of custom controls. These comments only appear on the front panel -- they don't tag along with the control when it is dropped.

And about wire labels... it would be nice to incorporate some flexibility into the display style of the labels (directional arrows, placement, etc), and if the wire gets kinda long…. Can we duplicate the label automatically every so many pixels?

Right... the control does not write to the INI file right now. One of the methods I was working on when I posted was "make current values default" which would rewrite the default values in the ini file with the current values in the control.

What really makes this a prototype though are the UI quirks... there are several things you can do to get the control in a confusing UI state and the yellow faux tool tips that appear over the value or label in the tree control have confused the people that have tested this for me. Also, you might notice I hid the tree controls scroll bar and then added a scroll bar to the xcontrol... this is because the mouse wheel can scroll the tree control but does not trigger any LV event so its not possible for me to move the visible editor... and then things get inconsistent and confusing.

An event that would have made coding this MUCH simpler is a "lost focus" event... but currently no such thing exists.

From info-labview:

I have historically used NIs ini palette because it was there and the users do seem to like the ini format. One problem has been the initial code investment... I sometimes get bogged down coding configuration panels. Then NI gave us the x control and the first thing I thought of was abstracting the configuration code. So I have made an x control that looks like a tree control and has all the code to read an ini file and let the user change the parameters. It has two methods... "load ini" and "get parameter".

If anyone is interested I'd love to share the code with you and hopefully make it better.

George

I really underestimated the popularity of using an xcontrol for configuration files. So by popular demand, here is the prototype. The ini file format is as follows:

[tag] #use the parameters tag to reference it in code

description= #this text will appear in the caption below the tree control when this parameter is selected

section= #the parent of this parameter in the tree control

label= #what the user sees in the tree control

default= #obvious i hope

type= #one of STRING|COMBO|BOOLEAN|INTEGER|DOUBLE

selections= #applies only to combo boxes... separate items with a pipe (|)... add an * item to allow undefined strings (buggy)

format= #applies only to double, is the format string of the numeric display

minimum= #applies only to numeric types (integer, double)

maximum= #applies only to numeric types (integer, double)

Download File:post-478-1133280396.zip