Right now - Requried Terminal is identified by either 1. Bold text in Help window 2.Broken arrow.
Will it be posible to highlight / mark the required terminal, so to identify at first look ? Something like mentioned below.
Sorry i couldnt draw properly. but some thing like this to highlight both in FP and BD.
It's not secret that .NET or ActiveX object on front panel appears to be child window of NI container clipping window, which itself is a child of front panel window. When there's only one object in the container on FP, it is easy to get its window handle (HWND) by calling GetTopWindow or simply by iterating through all child windows of FP. This handle has to-one correspondence with automation refnum on block diagram. But when there are several .NET/ActiveX objects on the panel, it's impossible to identify their handles with refnums on BD.
The way of handle obtainment could be implemented by any of the following methods:
(or let it be private property, being activated with special *.ini key)
MgErr AutoRefNumToHWND(refNum, hwndp); - this variant is analogue of LabVIEW Manager function FRefNumToFD, where refNum is automation refnum of .NET/ActiveX object (type LVRefNum) and hwndp is pointer to child window handle (type HWND *).
Probably many people may consider this idea unimportant, but when it comes to drawing different shapes, displaying text, copying window content etc., my suggestion may be very relevant.
Wire : Right Click --> Visbile --> Label (Its void Now )
Solution : It can take the control Name as default label of the wire, instead of being Void
Not sure if this idea is already proposed.
(Inspired by this discussion)
The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).
The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.
NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.
I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.
For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).
Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?
I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.
In any case, this bug with most likely never be fixed.
The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.
My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.
After deleting items I don't want in the project, or loading plugins in a plugin architecture, I want to remove them from the LabVIEW memory. This is not possible now, as they go into Dependencies->Items in Memory.
The only way to do this now is to close and open the project, which over a large Plug-in architecture project is a real pain.
Ideally, I would like to right click the folder and choose "remove from memory". However, any option that allows this would be good.
.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:
Would be resized into:
Aesthetic issue: thick wires connected to Select inputs show as ugly corners behind the triangle icon, probably a result of the underlying connector pattern.This does not happen for other triangular blocks, at least not up to a reasonable wire thickness (to make a wire thicker, just make a N-dim array of something).
Problem: my code accesses many different properties of many different controls. I need to locate where a specific property of a particular control is read/changed.
I know that the Find panel offersi me the option of searching by text, like
but that is not the solution, because I need to type thename of the property, and because I may match many other objects with the same string (comments, other controls with the same property, etc.)
I'd like a faster way to get to where I need. For instance the contetual menu could offer Find/specific property according to where the right-click was.
How you ever had to design a SQL query? Probably
Usually I design these in MS SQL Server Management Studio, because its easy to test there. And I like that the sql code is colored, so its easy to see whats going on.
However, when I copy it into a string constant, the colors are gone:
But I noticed, that if I copy sql code into a mail or a document, the formatting from MS SQL Server Management Studio is preserved.
That is because the program stores RTF (rich text format) information on the clipboard.
Wouldnt It be nice if there was an 'Paste Special' or Quick Drop feature that preserved the RTF formatting when pasting text into a string constant or a documentation label?
Then it could look like this:
If you think that this could be a nice feature, then kudo this idea
This should work!! I know there are workarounds and I have used them but it would be much easier.
On Windows, you can define environment variables that auto expand to known directories. There are some variables that are already defined by the system. For example, %TEMP% automatically expands to c:\Users\<username>\AppData\Local\Temp OR WHEREVER THE USER MOVED TEMP DURING INSTALLATION. That's the important part .That makes it possible to write %TEMP%\abc as a symbolic path that works regardless of how the system gets reconfigured.
Users can define their own environment variables, and those get expanded when used in a path in the command line or Windows Explorer (the text entry region at the top of an Explorer window). On Linux and Mac, it is the equivalent of using $VARIABLENAME/abc, where VARIABLENAME is some user-chosen name.
[admin edit] Added background information on environment variables, and updated title to use the word "Environment" instead of "Environmental".
Very simple idea that can make locating the basic comparison functions more efficient (first two lines). Changing the order putting each comparison function and his counterpart below him would make easier to find the desired one.