Tomi Maila

My appologies Mike, but I'm annoyed by the fact that each time I open LAVA, I hear this bing sound cause of your post.

QUOTE(Paul_at_Lowell @ Dec 11 2007, 07:11 PM) I think it means that the value of the class constant differs from the class default value.

You don't need to place all VIs within the executable but you can also add VIs outside the executable into one or more support folder. If this is not a problems for you, then you can add your VIs you need to list into a support folder and list the content of that folder. I'm not sure if the content of LabVIEW executable is listable. If it is, there is no guarantee that it will remain such in future LabVIEW versions. So to play safe, you shouldn't rely on listing the content of the executable. Another thing you can do is to store the names of the VIs within the executable into an external file. Then use this file to get the list of the VIs in the executable.

Nick, thank you very much for your response with insider information It's also nice to hear that NI is using instance VIs itself. And the best of all, I found a workaround to use instance VIs references without static VI references that also builds properly.

QUOTE(Aristos Queue @ Dec 10 2007, 05:00 AM) I'm afraid I've already reported this issue and for technical reasons I cannot pull it back any more. I hope they are not going to close this hole. I guess it has been around since LV 7 and there is a large possibility that few of LabVIEW users are exploiting this hole. Closing the hole would also cause trouble to these customers.

Knowledge base article 'How to change plot colours based on a threshold?' seems to be more popular than it should... Something wrong with knowledge base user logging perhaps?

QUOTE(Jim Kring @ Dec 9 2007, 11:57 PM) Super! Thanks AQ for the suggestion.

QUOTE(Aristos Queue @ Dec 9 2007, 11:42 PM) I don't make any other assumptions than that the LabVIEW works the way it is documented Perhaps I've been using this feature for ages in development environment and now that I try to build an app, it doesn't work Anyway I already reported this as a bug and I'm going to push towards this bug being fixed in the next release. I still think it's a bug without doubt. Language features that work in development environment should also work in the build applications. Nobody can deny this. Let's take shift registers for an example. The intended use is to preserve data from one loop iteration to the next. Then someone came up with functional globals. I guess it wasn't the intended use but it was an excellent use case. Should such apps build properly even though they are using shift registers in contrast to it's original intended use? I guess everyone agrees that these apps should still build properly. I think we are talking about similar issue here. Instance VIs are used as subVIs so far. But the language has allowed creating static VI references to instance VIs since LabVIEW 7 Express I guess. Creating instance VI static references doesn't require black magic or usage of any undocumented features; simply drop an Express VI on BD and then drag it to a static VI reference node. Maybe referring to instance VIs was not the intended usage, but I find it very useful. Should an incorrectly working builder optimization algorithm prevent me from using this language feature? Or should the builder bug be fixed? I'd like to hear other opinions here! Please be free to comment. I'll promise you all something extremely cool later on that takes advantage of this language feature... As for when it comes to using reentrancy as a solution, yes it could work. However I think I need to use reentrancy parameter it its normal use cases. Otherwise it is a good suggestion. Tomi

QUOTE(tcplomp @ Dec 9 2007, 12:18 PM) I don't think this is possible to explicitly include an instance VI into a build. The instance VIs are saved within outer VI and I don't think you can explicitly select them to be included, at least not interactively. Maybe one could edit the build specification manually but that's not very user friendly. I'm working on a user friendly framework and am not ready to accept usability wise poor solutions. An instance VI path is something like C:\My Project\My Outer VI.vi\1 where 1 is the name of the instance VI. The qualified name of the instance VI is My library.lvlib:My Outer VI.vi:Instance:1 Actually I've not tested if instance VI will be included into the same library into which the outer VI belongs to. Tomi

QUOTE(Aristos Queue @ Dec 9 2007, 09:27 AM) I diagree. I think it is a bug. All VIs referred by static VI references should be included into the build. Instance VIs should not be any different in this respect. When I place any other subVI on the disable diagram and create a static VI reference to this subVI, builder includes the VI into the build, because I have the static VI reference referring to it. The method suggested using case structure instead of disable diagram doesn't work. LabVIEW reserves all VIs within case structure for subVI execution. Then they cannot be called with RunVI method because they are in a state Run not compatible with top-level exection. Tomi

Aristos Queue, it works! But only within development environment There seems to be a bug in builder that drops the instance VIs from the build... I reported it to NI and for their shake I hope they will fix it soon. I'm still going to use this method and if not fixed, I guarantee they are going to get a plenty of bug reports from you all If a static VI reference is created into an instance VI (Express VI isntance), the instance VI can be referred using a VI reference. If one wishes to use Run VI method, one needs to place the instance VI itself on a disable diagram to avoid reserving the instance VI for subVI exection when the main VI executes. This method works properly in development environment but build applications exit with internal error. It's presumable that builder simply mistakenly excludes the instance VI from the build. To reproduce: - Open the attached project - Open the only VI in the project - Run VI in the development environment, notice that the instance VI is executed properly - Now close the VI - Build an application according to the build specifications - Execute the application, note that it doesn't execute but stops at internal error

I would prefer object-oriented programming over GOOP. I think object-oriented programming is better recognized phrase than LVOOP.

QUOTE(Aristos Queue @ Dec 7 2007, 07:56 AM) Thank you, ah mister, for thy guidance! Thy words of wisdom of great help are! Lord praise you mister, lord praise.

QUOTE(PJM_labview @ Dec 6 2007, 07:48 PM) But in my use case I would never be able to save the VI into a file. It would only exist as a string buffer in a state information of an XNode. As LabVIEW doesn't know this particular string is a VI, it doesn't know that it needs to be recompiled every now and then. I was indeed looking for methods to get it recompiled without saving it to an external file. External file would be usability wise so bad an alternative that I cannot consider it as an option. Nobody would accept a situation where LabVIEW would generate several support VIs for every user defined VI on its own. Only if these VIs can be somehow stored within the VI and LabVIEW would load them into memory together with the VI with front panels closed, only then the solution would be acceptable. So is there a way to store a VI inside another VI and get LabVIEW to load the inner embedded VI into memory when the outer VI loads to memory and compile the inner VI like any other VI and save it together with the outer VI when ever the outer VI is saved?

It is possible to save a VI as a buffer (string) using scripting. A reference to this buffer saved VI can then be opend using scripting as well. The problem with this kind of VI is that LabVIEW doesn't know they exist and cannot recompile them when something referred by the VI changes. I'd like to script a top-level VI for each XNode instance so that the content of the scripted VI depdens on the configuration of the XNode. The important issue here is that the VI must be top-level i.e. I need to be able to call it asynchronously. At execution time XNodes are always called syncrhonously to my knowledge, aren't they? So I was thinking placing a static VI reference on the code generated by the XNode and use this reference to call the VI asynchronously using Run VI method. The problem is that I don't find good solution to do this. If I script a new VI, it needs to be saved somewhere. From usability point of view, the internal VI needs to be unexisting for the user. So I cannot save it into an external file. I could save it as a buffer that's stored as state parameter of the XNode. However I expect that this method would lead into many problems as LabVIEW cannot compile the VI in the buffer when something changes. For example if a VI containing such XNode is opened in another LabVIEW version, the buffer would not be recompiled properly. So I guess the only option I can think of is to save the VI within the XNode containing VI or the XNode instance somehow. I know LabVIEW class controls are VIs stored within an lvclass file. I'd like to kind of save my scripted VI within the VI as a kind of internal subVI that would be recompiled when the outer VI is recompiled. But I've no idea if this is possible. Does anyone have any idea if this is possible? I would not like to use explicit linker depdendesies as Aristos Queue so strongly demanded not to use them. That is always the last option left... Tomi

It executes three JavaScript functions from a JavaScript file that you didn't provide to do something with an XML file that you didn't provide either.

I've now done some research. Let's index the flag bits starting with zero from the most significant bit of the I16 flag. The bit 0 describes if the terminal is a dynamic dispatch terminal The bits 1-2 are unknown The bit 3 is 1 for required inputs and dynamic dispatch inputs and 0 otherwise (inputs that need to be connected) The bit 4 is 1 for recommended or optional input or output and 0 otherwise (terminal that doesn't need to be connected) The bit 5 defines if the output is in-place with an input (1) or not (0). The bit 6 is unknown The bit 7 describes if the terminal is an input (0) or an output (1) If bit 5 is 1, the bits 8-15 or 12-15 (unsure) tell if the output terminal is inplace with an input terminal. The input terminal index is encoded into these bits. The weird thing is that at least I cannot predict the inplaceness. I may have two identical VIs with identical block diagram and identical connector pane. One can pass error cluster in-place and the other cannot. It seems LabVIEW is not very deterministic in determining the inplaceness of an output. Actually it even seems that data doesn't have to be inplace in order for the output to be defined inplace. As an example an error out output terminal connected to a constant can be inplace with error in input connected to nowhere. For unconnected terminals the flag is 0 for all 16 bits. EDITED Dec 5 2007, 15.17 GMT. Tomi

Hi all, I know I have these weird questions all the time... This time I need to know what coding scheme for strictly typed VI reference connector pane flags. So I need to query using VariantDataType library the connector pane settings of strictly typed VI. The connector pane information is returned as an array of flags. Now I don't know the coding scheme of these flags. So does anybody know the meaning of these flags or do I need to reverse engineer them by myself? See the attached VI for details on how to retrieve these flags. Tomi

QUOTE(Aristos Queue @ Dec 5 2007, 01:49 AM) Ok. I will. At least for now. This project I can work out without linkage modifications. Though I've in my mind another project with which I couldn't avoid using... Do I correctly read between the lines that you have personal experience on fighting with linkage issues

Hi, Has anybody had any success with RefeeChanged ability? I tried to use Add Linker Reference method of XNode class to register my XNode to change when a VI is modified or when the VI path is changed. However I fail to succeed, I only get an error from Add Linker Reference method that the manager function is not supported. Tomi

QUOTE(Aitor Solar @ Dec 3 2007, 10:11 AM) I'm unable to find this Fake Exec State scripting property. Where can I find it? I was using your and my own scripting tool... EDIT: I found it, it was a method... Tomi

QUOTE(Aitor Solar @ Dec 1 2007, 10:05 PM) Hint: The solution can be found from the dark side.

QUOTE(i2dx @ Dec 1 2007, 01:35 PM) Actually the name of the event should not be "Value changed" but instead "Value edited" or "Value modified" or something similar. Actually I suggest adding a new event called "Value changed" which would function as Dave suggests i.e. the value change would be actually tested before signaling the event. So having "Value edited" and "Value changed" events would suit to all possible use cases. Tomi

QUOTE(Aristos Queue @ Dec 1 2007, 12:59 AM) I don't want this to be changed. I think this is correct behaviour. I think a value can be changed into the same value completely legally. I think value change event should be fired even when value is modified to be the same at it was previously. Does it trigger if I edit a path from C:\file and replace it with C:\file. I think value change should trigger. However if reinitialize to default values is invoked using scripting, then event should not be triggered. Is it? I don't have the time to check these out now.

What's wrong with this video?