Tomi Maila

I've a vision of new certainly interesting LabVIEW functionality I'd like to write an implementation. The best implementation of this new functionality would require a smartly functioning custom structure similar to timed sequence in a sense that there needs to be multiple consequetive diagram parts in the new structure with XNode style inputs and outputs in each of them. However unlike timed sequence, the functionality of this new diagram would not resemble sequence at all. Now the question is that I need all the possible ideas that you guys may have how this could be implemented. I'm somewhat familiar with simple XNodes that can act as smart subVIs with scriptable content, terminals and visual appearance. However I've no idea how could I implement a structure that could contain multiple segments of code inside it, scriptable inputs and outputs at each segment. In addition I'd need to be able to control if/when the segments are actually executed. Sounds like a challenge. That makes it an interesting task... Cheers, Tomi

Can you still verify if the USB board is physically attached to the student's client computer and not a server somewhere away from the student.

QUOTE(Narudol @ Oct 21 2007, 12:43 PM) Use LabVIEW application builder to build an executable application and allow users to download it to their local computer and run it from there. To run the application will need LabVIEW runtime environment. You can make an installer that installs both you application as well as the runtime environment. Tomi

QUOTE(Narudol @ Oct 20 2007, 01:25 PM) No, you must run LabVIEW or standalone LabVIEW build application on your user's computer to connect to hardware on user's computer. Tomi

QUOTE(Narudol @ Oct 19 2007, 11:09 AM) No you cannot embed VIs to HTML files so that it can be played online using local runtime engine. There is no such thing as a LabVIEW player for any web browser. At least not to my knowledge. However you can run LabVIEW in server mode and publish remotely running VIs via Java applet front panels. In this case, the VI is ran on the server machine running LabVIEW. A user can run the VI and access the VI front panel using a web browser. Should two person try to access the same VI remotely, they see the same instance of the VI, not two different instances of the VI as you'd propably expect. Tomi

QUOTE(Aristos Queue @ Oct 16 2007, 08:31 PM) No... For each dot in the 'classic' VI there exists a dot in the optimized VI in the exact same position. But there are a few additional dots in the optimized VI. Based on this information optimized VI should perform worse than the classic VI. Let's go even deeper to the world of inplaceness. I expect the classic VI to be something like the following as C++ code: MgErr f(Node** Node_in, LabVIEW_Object** Data, Root** Root_out){ // Block 1 // 'New Node' is a constant // Let's call the buffer originating from 'New Node' B Node_Handle B = Create_And_Copy_Buffer(New_Node); // Block 2 // Let's set the content of Next field of 'Node in' // buffer to the Next field of newly created buffer B // Let's also assume that LabVIEW is not smart enough to // notice that Next Field of 'Node in' would not be used // any more so it makes a buffer copy. (*B)->Next = Create_And_Copy_Buffer((*Node_in)->Next); // Block 3 // Let's set the content of Data buffer // to the Data field of newly created buffer B // Let's also assume that LabVIEW is smart enough to // reuse the original Data buffer (*B)->Data = Data; // Block 4 // Let's place the buffer B to the Next field of // 'Node in' buffer (*Node_in)->Next = B; // Block 5 // Return value Root_out = Node_in; // Block 6 // Exit return noErr; } I divided the code into six blocks. Let's compare the code with the actual LabVIEW code in the left hand side picture above. I expect the buffer allocation dots next to each constant and control to indicate buffer allocations that occur when VI is loaded to memory. These buffer allocations are not present in the C++ code above. So let's take a deeper look at the block 1. In this block we copy the content of New Node constant to a new buffer that we call B. I expect LabVIEW buffer allocation tool to show this action as a dot on the bundle node which is directly connected to New Node constant. Is this right? If I'm right here, I must say this way of presenting the buffer allocations is unintuitive to me. I'd rather have the buffer allocation dot above the bundle node at the end of the wire originating from the New Node constant. That's where the buffer allocation happens from the LabVIEW programmer point of view. In block 2 we make an (unnecessary and now avoidable) memory copy of by copying the content of Next field of Node In to the Next field of B. Show buffer allocations tool shows this allocation with a dot at the exactly same position as the dot for buffer allocation in block 1. So I assume there is no way for me to distinguish these two dots. So let's see what happens in the optimized VI then. We have the buffer allocation of block 1 as before. We should not have the buffer allocation of block 2. Still we have all the same dots as before. There is now something I don't understand. To make the issue even more complicated I decided to make another inplace version of the VI. The VI is below. The buffer allocations are marked with red rectangles as before. http://lavag.org/old_files/monthly_10_2007/post-4014-1192655221.png' target="_blank"> Now according to LabVIEW there are fewer buffer allocations than in the exaple AQ posted. I must say I'm really confused. If someone is not, I congratulate. P.S. A nice feature for the show buffer allocation tool would be to allow showing only dynamic buffer allocations and not static load time buffer allocations. These two allocations are very different in nature and require different optimizations. Second it would be nice if the buffer allocations could be shown at the inputs of nodes and not only at the output of nodes. This is especially true for the bundle node as it would be nice to know the buffer that is allocated exactly.

QUOTE(Norm Kirchner @ Oct 16 2007, 06:59 PM) Actually I think there is either a bug in show buffer allocations algorithm or the swap node doesn't work as it should or AQ didn't use it properly. Can anyone confirm which of these three options is the valid one. Tomi

QUOTE(Darren @ Oct 15 2007, 10:06 PM) Cause you can create a desktop shortcut for this

QUOTE(Aristos Queue @ Oct 15 2007, 07:22 PM) Unlike in C++, a static method of a child class in LabVIEW wouldn't shadow its parent method because LabVIEW can always use fully qualified names to make the call. Text based programming languages suffer from the fact that users don't want to write long fully qualified names. In LabVIEW one doesn't need to write but simply drop a corresponding method to block diagram.

Hi, I'd really love to see the following change in LabVIEW OOP. Currently static dispatching class methods cannot have the same short name as the methods in any of the ancestor classes. As a result, if I've a static dispatch ancestor method say Initialize.vi, then I cannot have a VI with the same name in my descendant class. As an example consider a parent class Root and a child class Node from Aristos Queue's linked list example. Consider that you wanted to be able to Initialize objects of both classes. To make naming convention uniform, it would be natural to call these initialization methods Initialize across the hierarchy. It would make it easier for the class user to identify the initialization method to be used. However this is not possible. Adding a Initialize.vi to both classes would break the classes resulting in broken arrow even when the VIs are static dispatch VIs. Still the VIs would have unique qualified name i.e. long name of the form Class Name.lvclass:Initialize.vi. The advantages of allowing methods at different levels of class hierarchy to have same names are: Method naming would be simpler and uniform method names could be utilized across the classes for similar functionality It would be easier for the class user to identify functionalities such as Initialize, Create or Close Call Parent Method primitive could be extended to function also with static dispatch method of the same name. The linking can be done at compile time and this would only be short cut to finding the parent method with a same name. This would be valuable for initialization where a constructor method such as Initialize could easily call parent constructor with different connector pane. The only downside of allowing multiple methods in the hierarchy to have the same name is that this would limit the class developer of changing a static dispatch method into a dynamic dispatch method later on. If you support this idea or are against it, please comment. We can gather feedback for LVOOP R&D team...

QUOTE(Aristos Queue @ Oct 15 2007, 01:44 AM) It makes sense logically. Not that I see inplace operations to be crucial for the functionality but only for efficiency of the implementation. I asked this question cause I understood that the inplace operations are required to make the functionality safe but now I understand that even without inplace operations everything should functionally work properly and inplace operations only make memory efficiency better. However playing hide the dots game doesn't support your statement of inplace operations making the memory efficiency better. Compare the images below. I've used red rectangles to make the dot's easier to identify. QUOTE(Aristos Queue @ Oct 15 2007, 09:54 AM) Or assert the inplaceness with the new tools in LV8.5. What new tool?

QUOTE(Aristos Queue @ Oct 14 2007, 10:19 PM) I'll eagerly wait for the LabVIEW version where I can get rid of case structures entirely by simply using LVClasses

QUOTE(Justin Goeres @ Oct 12 2007, 11:05 PM) Don't loose your hope yet... take a look at the dates of the post Mike refers to. It's rather old, isn't it.

QUOTE(yen @ Oct 12 2007, 04:33 PM) This key was for previous LabVIEW beta... I can't recall the INI key. I don't know if it still works in the release version.

QUOTE(Milchbilch @ Oct 12 2007, 11:44 AM) If you have a wire of type parent class that contains a child class instance and the wire terminates to dynamic dispatch input of your parent class member VI, then the child class member VI with the same name is executed instead if one exists. If on this child class VI block diagram, there is a 'call parent method' node, then and only then the parent method is called as well. The parent method in this case behaves as if it was a regular subVI on the block diagram of the child method. If immediate parent doesn't implement this method but the method is implemented in an ancestor class, then the method of closest ancestor is called with the call parent method primitive. Tomi

QUOTE(Justin Goeres @ Oct 12 2007, 02:14 PM) Actually I think NI is mixing two different concepts here, namely protecting the VI and locking the VI context. A VI could have multiple contexts. It could be part of a library. It could be on a block diagram of another VI etc. Password protecting a VI has until now meant hiding the implementation of the VI. Now it seems that NI has added a second meaning, namely locking the VI context as well. I think this is not how it should be as it limits the usage of password protection to only those cases where you want to lock the context as well. With this design NI is actually limiting the usage of password protection. For me the correct behavior is such that when a VI is password protected, then its implementation is hidden and nothing more. There could be new security options in addition to this old 0) 'hide block diagram and VI options' option. New options could include 1) don't allow dropping the VI to block diagrams, 2) don't allow executing VI independently. However I think it's a property of library to lock some or all items to the library. So if we need such a functionality that a VI is tied to a specific library, then we need to modify the security options of the library and not the VI. So I propose a change to the next LV version such that any LabVIEW library could lock its items but not the other way around. A VI should always be removable from a library. I agree with current functionality in that when a locked VI is removed from a library, then it becomes broken as this would mean a change to VI. However there could be a new security option 'allow context changes' that would allow renaming the VI as well as dropping it to a library even when password protected. Cheers Tomi

QUOTE(Justin Goeres @ Oct 10 2007, 04:58 PM) I guess it would. But I understood the problem was to fix the library by removing an unnecessary VI from the library. So it doesn't matter if the VI still thinks it's part of the library as it's no longer used. And the library doesn't think the VI is part of it. This can be achieved to my knowledge by editing the lvlib/lvclass/xcontrol/xnode file. Cheers, Tomi

QUOTE(Christina Rogers @ Oct 9 2007, 11:55 PM) I think this behavior should be considered as a bug! One should always be able to remove a VI from a library if one has the password of the library or if the library is not password protected. Owner of the library should be able to modify the library as he/she will. However removing the password protected VI from the library should not modify the password protected VI. That VI should still think it's part of the library and as it really is not, it should be removed from the project all together. Then for hackers a quick solution to solve the problem. Open the lvlib file and remove the password protected VI with your favorite text or XML editor. Save the lvlib file and close it. Then open it with LabVIEW and the VI should no longer be part of your library nor your life. Cheers, Tomi

QUOTE(Gabi1 @ Oct 9 2007, 06:04 PM) Yes you are thinking something wrong. Enums are a compile time way to make numbers have a meaning attached to them. I would never ever try to modify enums at runtime. It simpy doesn't make any sense. If you want your logic to depend on strings rather than numbers, then use string per se. Store a string to your private data and wire the string to the conditional terminal of your case structures. Tomi

QUOTE(Jim Kring @ Oct 8 2007, 09:37 AM) I could use required output to force by-reference objects to be properly closed.

QUOTE(Aristos Queue @ Oct 7 2007, 11:14 PM) If the factory is in the parent class, then you are stick with that factory implementation. First you can't easily change the implementation of the factory from one to another by simply changing the class implementing the factory. Second if you write a class hierarchy say image library. Then later on somebody else wants to extend your image library, then this somebody is married with your implementation of the factory as you've decided that the factory is a property of the parent class. Again it would be easier to extend the library if the factory wasn't part of the parent class but a class in a parallel hierarchy. I've always tried to follow the rule of thumb that keep classes clean of things that do not logically belong to the class. This rule of thumb gives often cleaner implementations that are easier to extend when the time comes. Following the rule may require some extra thought but saves a great deal later on. An ability to create different kinds of images is not a general property of a general image. Following the rule of thumb you should put it to a separate Image factory class. Actually I'd make the Image factory class abstract and then derive special implementing class from that. Sorry Tomi, AQ outranks you. smile.gif Then I've not done enough to show my talents Cheers, Tomi

QUOTE(eaolson @ Oct 6 2007, 09:42 PM) Works properly with LV 8.5. There must be a bug in LV 8.2.1. In Image.lvlib:Image.lvclass:All Image Types.vi you have an Image class array indicator, the default values of which contains all the child classes of Image class. I guess this doesn't load the child classes to memory in LV 8.2.1. Add class constants wired to build array wired to the indicator to All Image Types.vi. I guess this should be a workaround for the bug (or feature) but I've not tested. Second this VI and creating child classes in a method of parent class is bad OOP design as your parent class Image.lvclass should not be aware of its child classes. You're mixing functionality of a factory class with the functionality of a Image parent class. Google factory design pattern for more information on using factory classes for creating instances of other classes.

Actually there are both empty new VIs and VIs created from some sort of VI template. I think the VIs created from templates should always use the template default as the user selected connector pane may not always fit to the template. For example LabVIEW class methods are created from templates e.g. dynamic dispatch template, static dispatch template and accessor method tempaltes. Tomi

Yes, you should not be able to have a class instance flowing along a wire that is not in memory. So I guess you are encountering a bug. Can you provide an example that duplicates the issue, there could be something I'm not thinking of that you are doing that's actually causing the problem. Tomi

I second this proposal