|
Tag: Redirect target changed |
| (3 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| This is a list of the Ability [[VI]]s for [[XNodes]] in LabVIEW 8.20.
| | #REDIRECT [[List of XNode Abilities]] |
| (Originally created by Dany Allard and updated by Aitor Solar)
| |
| | |
| ==State==
| |
| ''Public name:'' '''State'''
| |
| | |
| This is a strict type definition that defines the state of your XNode. It should contain all the information you need to define an instance of your XNode. There should be no state information stored inside any of the XNodes ability VIs.
| |
| | |
| ==AdaptToInputs==
| |
| ''Public name:'' '''AdaptToInputs'''
| |
| | |
| This ability VI is called by LabVIEW during type propagation so that your XNode may adapt itself to new input types. Term Types is an array of pairs of current Term IDs and the type descriptors corresponding to them. The type descriptors are taken from the signal connected to the terminal. Unwired terminals are not included in the array. Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==AugmentSelf==
| |
| ''Public name:'' '''AugmentSelf'''
| |
| | |
| This ability VI is called when you want to add things to the XNode's owning diagram via LabVIEW's scripting API. This VI is only called when you have previously informed LabVIEW that you want to augment the XNode through a AugmentSelf reply. Diagram is a reference to a diagram of a temporary VI that has a stand-in for your XNode connected to terminals. This diagram contains exactly one front panel terminal for each terminal of your XNode which represent whatever is connected to your XNode. Terms is an array of pairs of Term IDs and terminal references. LabVIEW will move the code scripted into this diagram onto the diagram of the VI containing your XNode and connect everything to the correct terminals. (If you want to get rid of the XNode delete it from this dummy, otherwise it will be there when you're done.) The front panel terminals that are on this diagram are special in that they can only be on the top level diagram.
| |
| | |
| ArgumentString is user specified to pass any special information to AugmentSelf.
| |
| | |
| Augment Self? is used to tell LabVIEW whether or not you want to copy the scripted diagram over. If there is an error and you wish not to commit the changes, then the old XNode behavior will be left unchanged. It will not be called again until you indicate that it should be through the reply on another ability VI.
| |
| | |
| You should not use the Copy scripting method to move code into the temporary VI. This will adversely affect the user's clipboard. You should use the Move scripting method instead.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: ReplaceSelf
| |
| | |
| ==AutotoolRegions==
| |
| ''Public name:'' '''GetAutotoolRegions'''
| |
| | |
| This ability VI is called by LabVIEW to determine which tool to use when hovering over an xnode in edit mode, if autotool is turned on. The Bounds of each region is a rectangular region of the xnode in coordinates relative to the top left corner of the xnode. Tool is the autotool that should be used when the user hovers over the particular region of the xnode.
| |
| | |
| LabVIEW will sort the Regions by Priority so that lower priority regions are tried first in determining what tool to use.
| |
| | |
| This VI cannot override autotool behavior on grow handles and terminal whiskers of xnodes.
| |
| | |
| LabVIEW may cache the Regions array and can also call this VI if the Regions array is not currently cached. To force LabVIEW to call this VI and update its autotool regions, use the Reply of "UpdateAutotoolRegions".
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Bounds==
| |
| ''Public name:'' '''GetBounds'''
| |
| | |
| This ability VI is used to tell LabVIEW your current bounds. If you want to update your bounds, you must inform LabVIEW through the UpdateImageAndBounds reply of another ability VI. If you change your bounds, you will also probably want to update your image.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==BuildMenu (deprecated)==
| |
| ''Public name:'' '''BuildMenu2'''
| |
| | |
| This ability is deprecated; prefer '''BuildMenu3'''.
| |
| | |
| This ability VI is used to describe the menu LabVIEW will display in response to a popup (right) click or a ShowMenu reply from OperateClick.
| |
| | |
| Click Type is the type of click that led to this call of the ability. Point is the location of the user's popup click, and is relative to the top-left corner of your XNode's bounds. You may use this point to make your popup sensitive to the location that was clicked. Show Standard Items? is applicable only if Click Type is Popup, and tells LabVIEW whether it should include the standard popup items that are included on every node in LabVIEW.
| |
| | |
| Menu Specification is an array of clusters describing the menu.
| |
| Item: A string that will appear in the menu.
| |
| StartSub: The current string will be the header for a pull right menu.
| |
| EndSub: The current string will be the last item in a pull right menu.
| |
| Checked: The current item will have a check mark next to it.
| |
| Disabled: The current item will be diabled and greyed out.
| |
| Separator: The current item will be a separator. Item string is not displayed.
| |
| Help: The text that should be displayed in context help when this menu item is hovered over. This functionality is currently not implemented.
| |
| | |
| The index from this array will be an input to SelectMenu.
| |
| | |
| Remember to localize the strings in your menu.
| |
| | |
| ''Default behavior:'' Only show standard items for a popup click, show nothing for operate click.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: SelectMenu
| |
| | |
| ==BuildMenu3==
| |
| ''Public name:'' '''BuildMenu3'''
| |
| | |
| This ability VI is used to describe the menu LabVIEW will display in response to a popup (right) click or a ShowMenu reply from OperateClick.
| |
| | |
| Click Type is the type of click that led to this call of the ability. Point is the location of the user's popup click, and is relative to the top-left corner of your XNode's bounds. You may use this point to make your popup sensitive to the location that was clicked. Show Standard Items? is applicable only if Click Type is Popup, and tells LabVIEW whether it should include the standard popup items that are included on every node in LabVIEW.
| |
| | |
| Menu Specification is an array of clusters describing the menu.
| |
| Item: A string that will appear in the menu.
| |
| Id: A string that identifies this item and will be passed to SelectMenu3.
| |
| StartSub: The current string will be the header for a pull right menu.
| |
| EndSub: The current string will be the last item in a pull right menu.
| |
| Checked: The current item will have a check mark next to it.
| |
| Disabled: The current item will be diabled and greyed out.
| |
| Separator: The current item will be a separator. Item string is not displayed.
| |
| Help: The text that should be displayed in context help when this menu item is hovered over. This functionality is currently not implemented.
| |
| | |
| The index from this array will be an input to SelectMenu3.
| |
| | |
| Remember to localize the strings in your menu.
| |
| | |
| ''Default behavior:'' Only show standard items for a popup click, show nothing for operate click.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: SelectMenu3
| |
| | |
| ==BuildPopup (deprecated)==
| |
| ''Public name:'' '''BuildMenu'''
| |
| | |
| This ability is deprecated; prefer '''BuildMenu3'''.
| |
| | |
| This ability is used to describe your popup menu. Point is the location of the user's popup click, and is relative to the top-left corner of your XNode's bounds. You may use this point to make your popup sensitive to the location that was clicked. Show Standard Items? tells LabVIEW whether it should include the standard popup items that are included on every node in LabVIEW.
| |
| | |
| PopUp Specification is an array of clusters describing the menu.
| |
| Item: A string that will appear in the menu.
| |
| StartSub: The current string will be the header for a pull right menu.
| |
| EndSub: The current string will be the last item in a pull right menu.
| |
| Checked: The current item will have a check mark next to it.
| |
| Disabled: The current item will be diabled and greyed out.
| |
| Separator: The current item will be a separator. Item string is not displayed.
| |
| | |
| The index from this array will be an input to SelectPopup.
| |
| | |
| Remember to localize the strings in your menu.
| |
| | |
| ''Default behavior:'' Only show standard items.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: SelectPopUp
| |
| | |
| ==CanAcceptDataDrag (deprecated)==
| |
| ''Public name:'' '''CanAcceptDataDrag'''
| |
| | |
| This ability is deprecated; prefer '''CanAcceptDataDrag2'''.
| |
| | |
| This ability VI is used to specify whether your XNode can accept either string or path data drags. Currently Point is always (0, 0).
| |
| | |
| ''Default behavior:'' Reject data drags.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: DataDrag, GetDataForDrag
| |
| | |
| ==CanAcceptDataDrag2==
| |
| ''Public name:'' '''CanAcceptDataDrag2'''
| |
| | |
| This ability VI is used to specify whether your XNode can accept either string, path, or project item data drags. Currently Point is always (0, 0).
| |
| | |
| ''Default behavior:'' Reject data drags.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: DataDrag2, GetDataForDrag
| |
| | |
| Compare
| |
| ''Public name:'' Compare
| |
| | |
| This ability VI is used to compare two instances of your XNode and report the differences to LabVIEW. Data In is the state information of the other instance of your XNode.
| |
| | |
| Diffs is an array of clusters describing the differences.
| |
| Major?: A value of true indicates that the difference is a major one. A value of false indicates a minor one.
| |
| Functional?: A value of true indicates that the difference is functional. A value offalse indicates that it is cosmetic.
| |
| Description: A description of the difference. Remember to localize it.
| |
| | |
| ''Default behavior:'' Report no differences based on state. LabVIEW will still report changes in terminal configuration or bounds. If you implement this method, LabVIEW will not check your terminals or bounds for you, but it will still check breakpoints, descriptions, and labels.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Copy==
| |
| ''Public name:'' '''Copy'''
| |
| | |
| This ability VI is called by LabVIEW after the user copies an XNode. State In is the same as the original XNode's state. The generated code is copied from the old XNode and will not be regenerated unless you return the GenerateCode reply.
| |
| | |
| ''Default behavior:'' Produce an exact copy of the original XNode without regenerating the code.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: Initialize
| |
| | |
| ==DataDrag (deprecated)==
| |
| ''Public name:'' '''OnDataDrag'''
| |
| | |
| This ability is deprecated; prefer '''DataDrag2'''.
| |
| | |
| This ability VI is called by LabVIEW when your XNode receives a data drag. Either String or Path will have a non-empty value depending what data the drag element can supply and what data CanAcceptDataDrag indicated your XNode could receive. If you accept both strings and paths, and the drag element can provide both, then path is provided and string is empty. Currently Point is always (0, 0). Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: CanAcceptDataDrag, GetDataForDrag
| |
| | |
| ==DataDrag2==
| |
| ''Public name:'' '''OnDataDrag2'''
| |
| | |
| This ability VI is called by LabVIEW when your XNode receives a data drag. Some combination of String, Path, and ProjectRef will have a non-empty value depending what data the drag element can supply and what data CanAcceptDataDrag2 indicated your XNode could receive. Currently Point is always (0, 0). Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: CanAcceptDataDrag2, GetDataForDrag
| |
| | |
| ==DisplayName==
| |
| ''Public name:'' '''GetDisplayName'''
| |
| | |
| This ability is deprecated; prefer '''GetDisplayName2'''.
| |
| | |
| This ability VI is used to supply LabVIEW with the name of your XNode. This is used as the default value for the label, it is used to mark entries in the error list and the difference list.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==DoubleClick==
| |
| ''Public name:'' '''OnDoubleClick'''
| |
| | |
| This ability VI is called when the user double clicks on your XNode. Point is the the location on the XNode that the user clicked relative to the top-left corner of the XNode. A common pattern is to open a configuration dialog when the user double clicks on an XNode, but you may choose to behave differently. Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| ==Feedsthrough==
| |
| ''Public name:'' '''CalculateFeedthrough'''
| |
| | |
| This ability VI is used by the Simulation diagram to calculate feedsthrough.
| |
| | |
| This is an advanced feature for Simulation.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==GenerateCode==
| |
| ''Public name:'' '''GenerateCode'''
| |
| | |
| This ability VI is called when it is time to define the execution behavior of your XNode via LabVIEW's scripting API. This VI is only called when you have previously informed LabVIEW that you need to script through a GenerateCode reply. Diagram is a reference to a diagram of a temporary VI. This diagram contains exactly one front panel terminal for each terminal of your XNode. Terms is an array of pairs of Term IDs and terminal references. LabVIEW will copy code scripted into this diagram into your XNode and connect everything to the correct terminals. The front panel terminals that are on this diagram are special in that they can only be on the top level diagram.
| |
| | |
| Generate Code? is used to tell LabVIEW whether or not you want to copy the scripted diagram over. If there is an error and you wish not to commit the changes, then the old XNode behavior will be left unchanged. If you set Generate Code? to false, then this VI will be called again next time type propagation is run. Otherwise, it will not be called until you indicate that it should be through the reply on another ability VI.
| |
| | |
| Because the diagram you are scripting into is separate from the VI containing the XNode instance, type propagation and the data manager will run on the temporary VI after each scripting call.
| |
| | |
| You should not use the Copy scripting method to move code into the temporary VI. This will adversely affect the user's clipboard. You should use the Move scripting method instead.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: ModifyCode
| |
| | |
| ==GetDataForDrag==
| |
| ''Public name:'' '''GetDataForDrag'''
| |
| | |
| This ability VI is used to supply data when your XNode is dragged over a data socket (such as a path or string control). String Valid? and Path Valid? indicate if you can supply that type of data, and String and Path contain the data.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: CanAcceptDataDrag2, DataDrag2
| |
| | |
| GetDisplayName2
| |
| ''Public name:'' '''GetDisplayName2'''
| |
| | |
| This ability VI is used to supply LabVIEW with the name of your XNode. This is used as the default value for the label, it is used to mark entries in the error list and the difference list.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==GetErrors3==
| |
| ''Public name:'' '''GetErrors3'''
| |
| | |
| This ability VI is used to tell LabVIEW about errors involving your XNode instance. The Errors array is a cluster of errors that will show up as block diagram errors in LabVIEW's error window. The cluster is made up of the errors in the list, the long descriptions of the errors that show up in LabVIEW's error window's details box, and a help file and topic within that file that links this error to the specified help file via the Help button. The help file is the name of the file (*.chm), not the full path and needs to be part of LabVIEW. You only need to populate the array when Generate Strings? is true. You always need to correctly set the Errors Present? indicator. If you are generating strings, then Errors Present? should be true if and only if Errors is not empty. If errors are present, the VI containing the XNode will be broken.
| |
| | |
| Remeber to localize your errors.
| |
| | |
| ''Default behavior:'' Generate generic error messages if the code you script is invalid, or a required terminal is unwired.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==GetTerms3==
| |
| ''Public name:'' '''GetTerms3'''
| |
| | |
| This ability VI is used to describe your terminals to LabVIEW. Terms is an array of clusters describing the XNode's terminals.
| |
| ID: A unique string identifying the terminal.
| |
| Name: The name of the terminal visible to the user. Remember to localize it.
| |
| Type: The data type of the terminal (as a Variant). The data put in the variant will be used as the default for the input terminal if it's left unwired.
| |
| Bounds: A rectangle defining the bounds of the terminal relative to the bounds of the XNode. The bounds must be within the bounds of the XNode, and for whiskers to draw properly, they must be flush with at least one side of the XNode.
| |
| Input?: Indicates whether or not this terminals is an input.
| |
| Required?: Indicates whether the user must wire this terminal for the XNode to not be broken. Ignored on outputs.
| |
| Recommended?: Indicates whether the terminal is recommended.
| |
| Hidden?: Indicates whether the terminal is hidden. When a terminal is hidden, it cannot be wired to via user interaction or scripting. However, if it is already wired to when the hidden flag is changed to true, it will remain wired.
| |
| Adaptive?: Indicates that the term should change to match the type of its source if it is wired.
| |
| Direction?: Indicates what direction the wire stub should point. Choose auto to let LV decide based on the terms bounds being on the nodes edge.
| |
| | |
| The IDs are used by LabVIEW to keep track of your terminals. When you respecify your terminals, LabVIEW can tell whther terminals are new, deleted, or moved by the unique IDs. The order is irrelevant. If you move a terminal, then any wire connected to it will move with it.
| |
| | |
| If you want to update your terminals, you should return the UpdateTerms reply in one of your ability VIs.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==GrowInfo==
| |
| ''Public name:'' '''GetGrowInfo'''
| |
| | |
| This ability VI is used to describe your XNode's grow behavior. GrowInfo is a cluster containing the following elements:
| |
| Min Bounds: The minimum bounds of your XNode.
| |
| Max Bounds: The maximum bounds of your XNode.
| |
| Vertical Increment: The vertital grow increment of your XNode. Zero is interpreted as a one pixel increment.
| |
| Horizontal Increment: The horizontal grow increment of your XNode. Zero is interpreted as a one pixel increment.
| |
| Maintain Aspect?: Indicates that your XNode should maintain aspect ratio.
| |
| Oval?: Indcates that your grow lines are drawn as an oval instead of a rectangle.
| |
| Vertical Only Resize?: Indicates that your XNode only grows vertically.
| |
| Horizontal Only Resize?: Indicates that your XNode only grows horizontally.
| |
| Resize None?: Indicates that your XNode can not be resized.
| |
| | |
| ''Default behavior:'' Indicate that your XNode cannot be resized.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: Size
| |
| | |
| ==Help==
| |
| ''Public name:'' '''GetHelp'''
| |
| | |
| This ability VI defines the XNode's context help (CH) and online help (OH) behavior.
| |
| | |
| Standard Help Info: Consists of a Description (an explanation of the XNode to appear in CH window), and Path and Tag to the OH compiled html file.
| |
| Use Detailed Help?: Set to false to allow the default context help and online help to be built using only those fields in Standard Help Info. Set to true to specify, in Detailed Help Info, the context help image and terminals to be drawn in context help.
| |
| Detailed Help Info: Consists of an Image to display to the CH window, the Bounds of this image, and the Terms to draw in the CH window for this Image.
| |
| Use Subitem Help? and Subitem Help Info: Reserved for future use.
| |
| | |
| This ability VI is called whenever the CH system calls needs to update the CH window, and on a right click (to get the OH Path and Tag). The CH system is guaranteed to update the CH window whenever any of the following replies is sent: UpdateHelp, UpdateImage, UpdateImageAndBounds, UpdateLabel, UpdateTerms.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Image==
| |
| ''Public name:'' '''GetImage'''
| |
| | |
| This ability VI is used to describe your XNode's appearance. The origin of Image corresponds to the top-left corner of your XNode. The bounds of your XNode are used to crop this image. If you want LabVIEW to update your image, you need to inform it through the UpdateImage or UpdateImageAndBounds replies. Any areas where you do not draw are transparent, so regions intended to appear white should be explicitly drawn.
| |
| | |
| Remember to localize any strings that are part of your image.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Initialize==
| |
| ''Public name:'' '''Initialize'''
| |
| | |
| This ability VI is called when your XNode is first dropped. It is used to specify your initial state.
| |
| | |
| ''Default behavior:'' Intialize state to default defaults (usually zero-initialized).
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: Copy
| |
| | |
| ==ListErrors (deprecated)==
| |
| ''Public name:'' '''GetErrors'''
| |
| | |
| This ability is deprecated; prefer '''ListErrors2'''.
| |
| | |
| This ability VI is used to tell LabVIEW about errors involving your XNode instance. The Errors array is the list of errors that will show up as block diagram errors in LabVIEW's error window. The Details array contains the long descriptions of the errors that show up in LabVIEW's error window's details box. You only need to populate the arrays when Generate Strings? is true. You always need to correctly set the Errors Present? indicator. If you are generating strings, then Errors Present? should be true if and only if Errors is not empty. If errors are present, the VI containing the XNode will be broken.
| |
| | |
| Remeber to localize your errors.
| |
| | |
| ''Default behavior:'' Generate generic error messages if the code you script is invalid, or a required terminal is unwired.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==ListErrors2 (deprecated)==
| |
| ''Public name:'' '''GetErrors2'''
| |
| | |
| This ability is deprecated; prefer '''GetErrors3'''.
| |
| | |
| This ability VI is used to tell LabVIEW about errors involving your XNode instance. The Errors array is a cluster of errors that will show up as block diagram errors in LabVIEW's error window. The cluster is made up of the errors in the list, the long descriptions of the errors that show up in LabVIEW's error window's details box, and a help file index that links this error to a help file via the Help button. You only need to populate the array when Generate Strings? is true. You always need to correctly set the Errors Present? indicator. If you are generating strings, then Errors Present? should be true if and only if Errors is not empty. If errors are present, the VI containing the XNode will be broken.
| |
| | |
| Remeber to localize your errors.
| |
| | |
| ''Default behavior:'' Generate generic error messages if the code you script is invalid, or a required terminal is unwired.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Message==
| |
| ''Public name:'' '''Message'''
| |
| | |
| This ability VI is a means to send custom messages to your XNode. It may be called through scripting, or directly from the LabVIEW source code.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: MessageWithUI, MessageWithoutEffect, MessageWithUIWithoutEffect
| |
| | |
| ==MessageWithUI==
| |
| ''Public name:'' '''MessageWithUI'''
| |
| | |
| This ability VI is a means to send custom messages to your XNode. It may be called through scripting, or directly from the LabVIEW source code.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: Message, MessageWithoutEffect, MessageWithUIWithoutEffect
| |
| | |
| ==MessageWithoutEffect==
| |
| ''Public name:'' '''MessageWithoutEffect'''
| |
| | |
| This ability VI is a means to send custom messages to your XNode. It may be called through scripting, or directly from the LabVIEW source code.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: Message, MessageWithUI, MessageWithUIWithoutEffect
| |
| | |
| ==MessageWithUIWithoutEffect==
| |
| ''Public name:'' '''MessageWithUIWithoutEffect'''
| |
| | |
| This ability VI is a means to send custom messages to your XNode. It may be called through scripting, or directly from the LabVIEW source code.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: Message, MessageWithUI, MessageWithoutEffect
| |
| | |
| ==ModifyCode==
| |
| ''Public name:'' '''ModifyCode'''
| |
| | |
| This ability VI is called when it is time to define the execution behavior of your XNode via LabVIEW's scripting API. This VI is only called when you have previously informed LabVIEW that you need to script through a ModifyCode reply. Diagram is a reference to a diagram with your VI's current code (generated from the previous GenerateCode or ModifyCode call). This diagram contains exactly one front panel terminal for each terminal of your XNode. Terms is an array of pairs of Term IDs and terminal references. LabVIEW will copy code scripted into this diagram into your XNode and connect everything to the correct terminals. The front panel terminals that are on this diagram are special in that they can only be on the top level diagram.
| |
| | |
| Generate Code? is used to tell LabVIEW whether or not you want to copy the scripted diagram over. If there is an error and you wish not to commit the changes, then the old XNode behavior will be left unchanged. If you set Generate Code? to false, then GenerateCode will be called next time type propagation is run. Otherwise, GenerateCode or ModifyCode will not be called until you indicate that it should be through the reply on another ability VI.
| |
| | |
| Because the diagram you are scripting into is separate from the VI containing the XNode instance, type propagation and the data manager will run on the temporary VI after each scripting call.
| |
| | |
| You should not use the Copy scripting method to move code into the temporary VI. This will adversely affect the user's clipboard. You should use the Move scripting method instead.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: GenerateCode
| |
| | |
| ==MutateForPrevious==
| |
| ''Public name:'' '''MutateForPrevious'''
| |
| | |
| This ability VI is called when doing a save for previous on the xnode's containing VI. It is called after the SaveForPrevious governing VI is run, and allows you to specify a previous state/version cluster for your xnode when saved for 8.0. You may use the XRef to play with any xnode linker references. However, you should not muck with the xnode's containing VI through this reference.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: SaveForPrevious
| |
| | |
| ==OnFontChange==
| |
| ''Public name:'' '''OnFontChange'''
| |
| | |
| This ability VI is called when the XNode is loaded in a Block Diagram that was saved with different fonts. This ability gives the XNode the chance to update its Image, Bounds, and Terms based on the new font by letting this VI Reply that one or more of those abilities need to be called. If the XNode stores any of that information in its state, here is where it should be updated.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==OperateClick==
| |
| ''Public name:'' '''OnOperateClick'''
| |
| | |
| This ability VI is called when a user operate clicks on your XNode. Point is the point of the click relative to the top-left corner of your XNode. If you wish to show a menu in response to a user's operate click, issue the reply "ShowMenu". It is an error to issue this reply if you have not implemented the BuildMenu and SelectMenu ability VIs.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: BuildMenu3, SelectMenu3
| |
| | |
| ==RefeeChanged==
| |
| ''Public name:'' '''OnRefeeChange'''
| |
| | |
| This ability VI is called by LabVIEW when an item you have linked to is modified. You create links to items using methods available on the XRef.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==ReplaceSelf==
| |
| ''Public name:'' '''ReplaceSelf'''
| |
| | |
| This ability VI is called when you want to replace this XNode via LabVIEW's scripting API. This VI is only called when you have previously informed LabVIEW that you want to replace the XNode through a ReplaceSelf reply. Diagram is a reference to a diagram of a temporary VI. This diagram contains exactly one front panel terminal for each terminal of your XNode. Terms is an array of pairs of Term IDs and terminal references. LabVIEW will replace your XNode with code scripted into this diagram into the diagram of the VI containing your XNode and connect everything to the correct terminals. The front panel terminals that are on this diagram are special in that they can only be on the top level diagram.
| |
| | |
| Replace Self? is used to tell LabVIEW whether or not you want to copy the scripted diagram over. If there is an error and you wish not to commit the changes, then the old XNode behavior will be left unchanged. It will not be called again until you indicate that it should be through the reply on another ability VI.
| |
| | |
| You should not use the Copy scripting method to move code into the temporary VI. This will adversely affect the user's clipboard. You should use the Move scripting method instead.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: AugmentSelf
| |
| | |
| ==RespondToDrop==
| |
| ''Public name:'' '''OnDrop'''
| |
| | |
| This ability VI is called by LabVIEW after the XNode has been dropped on the block diagram. When it is called, Initialize, Image, etc. have all already been called. You can implement this ability VI to get express-like configuration page behavior on an XNode drop.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| ==SaveForPrevious==
| |
| ''Public name:'' '''SaveForPrevious'''
| |
| | |
| This ability VI is called by LabVIEW when a user does Save For Previous on the VI that contains this xnode. Use this VI to script a replacement for your xnode which can be saved for previous. The VI gives you a reference to a diagram that contains terminals corresponding to your xnode's terminals.
| |
| | |
| You script your replacement for the xnode into this diagram, and then your xnode is replaced with what you have scripted in the diagram, if Success? is true.
| |
| | |
| All XNodes run their SaveForPrevious method before traditional Save For Previous is done on the VIs containing the XNodes. Note that you should only script VIs and XNodes present in the previous labview version.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: MutateForPrevious
| |
| | |
| ==SelectMenu (deprecated)==
| |
| ''Public name:'' '''SelectMenu2'''
| |
| | |
| This ability is deprecated; prefer '''SelectMenu3'''.
| |
| | |
| This ability VI is called after the user selects an item from a portion of the menu defined during BuildMenu. Click Type is the type of click that led to the building of the menu whose selection is being handled by this VI. ItemIndex is the index of the element in the array used when you specified the popup menu. Point is the location where the user clicked to build the menu relative to the top-left corner of the XNode. You can display a dialog in response to a user selection if you wish. Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: BuildMenu
| |
| | |
| ==SelectMenu3==
| |
| ''Public name:'' '''SelectMenu3'''
| |
| | |
| This ability VI is called after the user selects an item from a portion of the menu defined during BuildMenu. Click Type is the type of click that led to the building of the menu whose selection is being handled by this VI. ItemIndex is the index of the element in the array used when you specified the popup menu. Id is the id you associated with the item in BuildMenu3. Point is the location where the user clicked to build the menu relative to the top-left corner of the XNode. You can display a dialog in response to a user selection if you wish. Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: BuildMenu3
| |
| | |
| ==SelectPopUp (deprecated)==
| |
| ''Public name:'' '''SelectMenu'''
| |
| | |
| This ability is deprecated; prefer '''SelectMenu3'''.
| |
| | |
| This ability VI is called after the user selects an item from a portion of the popup menu defined during BuildPopup. ItemIndex is the index of the element in the array used when you specified the popup menu. Point is the location where the user popup clicked relative to the top-left corner of the XNode. You can display a dialog in response to a user selection if you wish. Use Reply to inform LabVIEW of any actions it needs to take.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability provides UI and OS messages are handled.
| |
| | |
| See also: BuildPopup
| |
| | |
| ==Size==
| |
| ''Public name:'' '''OnResize'''
| |
| | |
| This ability VI is called by LabVIEW after the user resizes the XNode. Bounds is a recatangle whose coordinates are given relative to the old top-left corner of the XNode. You must either return a UpdateImageAndBounds reply or not return anything, otherwise LabVIEW will generate an error. If you return UpdateImageAndBounds, you may also return other reply strings.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| See also: GrowInfo
| |
| | |
| ==SpecifyInsertTerm==
| |
| ''Public name:'' '''SpecifyInsertTerm'''
| |
| | |
| This ability VI is used when a user inserts an XNode into a wire. It allows the user to specify which terminals to connect to the wire.
| |
| | |
| Point is the location of the joint to closest to where the node is being inserted.
| |
| | |
| IsSource? is true when a source terminal is being requested.
| |
| | |
| Type is the data type of the wire. (In theory, the XNode terminal you choose should be of the same type.)
| |
| | |
| TermOut is the string ID of the terminal you have chosen to connect the wire to.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Terms (deprecated)==
| |
| ''Public name:'' '''GetTerms'''
| |
| | |
| This ability is deprecated; prefer '''Terms2'''.
| |
| | |
| This ability VI is used to describe your terminals to LabVIEW. Terms is an array of clusters describing the XNode's terminals.
| |
| ID: A unique string identifying the terminal.
| |
| Name: The name of the terminal visible to the user. Remember to localize it.
| |
| Type: The data type of the terminal (as a Variant). The data put in the variant will be used as the default for the input terminal if it's left unwired.
| |
| Bounds: A rectangle defining the bounds of the terminal relative to the bounds of the XNode. The bounds must be within the bounds of the XNode, and for whiskers to draw properly, they must be flush with at least one side of the XNode.
| |
| Input?: Indicates whether or not this terminals is an input.
| |
| Required?: Indicates whether the user must wire this terminal for the XNode to not be broken. Ignored on outputs.
| |
| Recommended?: Indicates whether the terminal is recommended.
| |
| Hidden?: Indicates whether the terminal is hidden. When a terminal is hidden, it cannot be wired to via user interaction or scripting. However, if it is already wired to when the hidden flag is changed to true, it will remain wired.
| |
| | |
| The IDs are used by LabVIEW to keep track of your terminals. When you respecify your terminals, LabVIEW can tell whther terminals are new, deleted, or moved by the unique IDs. The order is irrelevant. If you move a terminal, then any wire connected to it will move with it.
| |
| | |
| If you want to update your terminals, you should return the UpdateTerms reply in one of your ability VIs.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==Terms2 (deprecated)==
| |
| ''Public name:'' '''GetTerms2'''
| |
| | |
| This ability is deprecated; prefer '''GetTerms3'''.
| |
| | |
| This ability VI is used to describe your terminals to LabVIEW. Terms is an array of clusters describing the XNode's terminals.
| |
| ID: A unique string identifying the terminal.
| |
| Name: The name of the terminal visible to the user. Remember to localize it.
| |
| Type: The data type of the terminal (as a Variant). The data put in the variant will be used as the default for the input terminal if it's left unwired.
| |
| Bounds: A rectangle defining the bounds of the terminal relative to the bounds of the XNode. The bounds must be within the bounds of the XNode, and for whiskers to draw properly, they must be flush with at least one side of the XNode.
| |
| Input?: Indicates whether or not this terminals is an input.
| |
| Required?: Indicates whether the user must wire this terminal for the XNode to not be broken. Ignored on outputs.
| |
| Recommended?: Indicates whether the terminal is recommended.
| |
| Hidden?: Indicates whether the terminal is hidden. When a terminal is hidden, it cannot be wired to via user interaction or scripting. However, if it is already wired to when the hidden flag is changed to true, it will remain wired.
| |
| Adaptive?: Indicates that the term should change to match the type of its source if it is wired.
| |
| | |
| The IDs are used by LabVIEW to keep track of your terminals. When you respecify your terminals, LabVIEW can tell whther terminals are new, deleted, or moved by the unique IDs. The order is irrelevant. If you move a terminal, then any wire connected to it will move with it.
| |
| | |
| If you want to update your terminals, you should return the UpdateTerms reply in one of your ability VIs.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==UpdateState (deprecated)==
| |
| ''Public name:'' '''UpdateState'''
| |
| | |
| This ability is deprecated; prefer '''UpdateStateWithRef'''.
| |
| | |
| This ability VI is called to perform mutation on an older version of an XNode. If a more recent version of an XNode's library exists, it will be called and let you mutate the old XNode's state appropriately to ensure compatibility with the newer XNode.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==UpdateStateWithRef==
| |
| ''Public name:'' '''UpdateState2'''
| |
| | |
| This ability VI is called to perform mutation on an older version of an XNode. If a more recent version of an XNode's library exists, it will be called and let you mutate the old XNode's state appropriately to ensure compatibility with the newer XNode. If you want to report a warning on load of a VI containing an xnode that has its state updated, you can use the reply "IssueWarning <Custom Load Warning goes here>". Note that most LV load warnings begin with "- ", so you will probably want to make yours conform to this standard. The load warning will only be issued if the state is successfully updated.
| |
| | |
| ''Default behavior:'' None.
| |
| | |
| This ability does not provide UI and OS messages are not handled.
| |
| | |
| ==HelpMap.vi==
| |
| ''<Not an ability>''
| |
| | |
| This VI is used for documentation. It is never called by LabVIEW, but it is the required mechanism for documentation. All Standard Help Info passed out of the Help ability VI should be generated from this VI. Simply create a label for each Description, Path, and Tag so that the documentation team can modify your documentation easily. Also create labels for any Subitem Help or Control Descriptions.
| |
| | |
| ==L10N.vi==
| |
| ''<Not an ability>''
| |
| | |
| This VI is used for localization. It is never called by LabVIEW, but it is the required mechanism for localization. All strings used by your XNode that are visible to the should be entered into the arrays on the front panel of this VI. The contents of the two arrays should be exactly the same. A localization tool will be run on this VI to translate the Localized Strings array, and this VI will map the original string to the new ones. Remeber to popup and select Data Operations>>Make Current Value Default after you modify the contents of the arrays. You shouldn't need to modify the block diagram. Just make sure that before you insert a string into a menu or image, you pass it to this VI to localize it. You don't need to do this with text appearing in dialogs if you tag the dialog as needing localization.
| |
| | |
| If you need to delocalize a string, then wire a false constant to the Localize terminal.
| |
