Tomi Maila

QUOTE(UserXXX @ Feb 14 2007, 02:22 PM) As long as the array on the C-side is of fixed size at compile time then yes, the cluster trick works. If your 2D array is a top-level parameter i.e. is not inside of a C struct, then you can also pass it directly as an array assuming you have initialized the array to correct size first on LabVIEW side. Select array for parameter type and array data pointer for parameter format. Tomi

QUOTE(robijn @ Feb 14 2007, 12:02 AM) Looks delicious! What is it that you are mixin... ?

QUOTE(Aitor Solar @ Feb 14 2007, 12:48 PM) Events get missed quite often in LV 7.1.1 if there is more than one event listener running simultaneously but I have not seen it occurring in LabVIEW 8.0.1 nor 8.20. I think events were fixes for LV 8. Tomi

Hi, Lava somehow automatically changed by thread layout to a tree hierarchy from my previous flat list threads. How can I change it back, I didn't find anything related from my controls. I just may be blind. For some reason I don't like these tree hierarchy layouts as I miss posts and I've to select what I read. I want to read it all... Tomi EDIT: I was blind. I found myself out. The option is on the top right corner of each thread.

Did you follow LV installation order from older to newer. Was all 7.1 components installed first and all 8.2 components after them?

The reason I asked about mixin class icons is that if mixin classes will be implemented somtime in the future (Aristos?) then there may really not be difference in the way one creates an abstract class and the way one creates a mixin class. Both are abstract and may have some functionality. The difference becomes in the way developer uses these classes. If the developer directly inherits from the class then it could be called abstract class. On the other hand if developer mixin inherits from the class then the class would be called mixin class. So the usage of the class determines if it is a mixin class or an abstract class. If this will be so in LabVIEW future version, perhaps the icon or glyph of the abstract classes should be such that it also fits to mixin classes. Right? On the other hand if the concepts will be distinct or if mixin classes will never be implemented, then of course I don't give a damn. Tomi

Hi I'd like to see the following modification in LabVIEW on the way towards fully object oriented language. Built-in types are not (yet) classes. However I would like to be able to pass them to subVIs as if they were classes. That is the LabVIEW type system should be modified so that built-in type can be connected to terminals that expect LabVIEW Object. Now it's not yet too late, as really nobody but me is using LVOOP. This would be a first step towards fully object-oriented language where all built-in types were classes as well. After you can pass built-in types as if they were classes, the next steps would be specifying a class hierarchy for built-in types and finally allow users to derive from these types. Primitive nodes such as 'plus' node could then either be class methods of each of the built-in type or functions that accept types that inherit from built-in types. Tomi

I didn't test this but I agree with you that I think it should function the way you expected.

Hi, I think we have consensus for the glyph of abstract class that is a wireframe cube. I'd like to challenge you with another glyph icon. What would be a proper symbol for mixin classes that hopefully will be added to LabVIEW in a future release... ? From wikipedia: So mixins are a generalization of Java like interfaces in that mixin class can already implement some of the methods. In languages with mixin classes a normal class can inherit from another normal or abstract class and in addition gather methods and private data members from one or more mixin classes. To avoid method name collisions, the directly inherited methods mask the mixin inherited methods. In addition when inheriting from multiple mixin clases, the mixin class that has been inherited first masks the methods in mixin class that is inhereted second and so on. Behind the scenes mixin classes are normally implemented so that mixin classes are really private data members of the class and method calls are delegated to the private data members by the runtime environment. A pseudocode example MyChildClass derives MyAbstractParentClass with MyFirstMixinClass with MySecondMixinClass{ MyMethod(x) { return MixinMethodOfFirstMixinClass(x)+MixinMethodOfSecondMixinClass(x) }} Tomi

I think it was LV 8.0 that came with new regexp node that works in a very similar way as Perl regexps. Could you consider upgrading to newer LV? Tomi

QUOTE(Jim Kring @ Feb 13 2007, 10:26 AM) Jim, you should have become an iconographer... Perhaps you can still change your career

I too don't like the DNA thing as it's not abstract at all. Especially not DNA if the name you are going to use is abstract. LabVIEW is uses a lot by life scientists and I don't think they link DNA to concept of abstract class. If you want a symbol for the inheritance, use inheritance tree. I also though of a ghost, but that's kind of stupid too. I think the best I can come up with is some geometrical object. Alternatively greek small letter alpha which symbols both beginning and abstract concept of mathematics. (I don't mean our firend alfa here at LAVA) Few geometrical objects I came up with. I think wireframe cube or some sort of hollow cube is the best as LabVIEW classes are symbolised by filled cube. Wireframe cube Klein Bottle Möbius strip Clebsch Diagonal Cubic

I already filed a bug report. Let the R&D decide if it's worth fixing.

QUOTE(alfa @ Feb 11 2007, 01:35 PM) How do you define aether? General Relativity simply says that all coordinate systems are equally good. Are you saying that there is a preferred coordinate system that is more fundamental than the other systems? Could you alpha explain why? Tomi

Super! :thumbup:

QUOTE(ragglefrock @ Feb 11 2007, 03:43 AM) Thanks, this is an interesting trick. However it doesn't solve the problem of genereting system events, only allows to handle system events and user events in the same event case.

The error implementation of the modern error cluster I proposed can be divided into two separate things. First the nodes thorw and catch any LabVIEW type using the error cluster. This can be implemented without modifying present code at all, simply add two new built-in nodes that would throw & catch any LabVIEW objects and extend the stacked sequence with a shift register. That would allow users to thow and catch errors in more complicated applications but would have simply no effect to those who didn't want to use this more advanced error system. Tomi

Please, no double posts.... Well, your post is not very informative. At least tell a LabVIEW version you are using, the type of the array contant and what happens when you resize the constant (don't let us guess). It would also be helpful if you attached an image. With the information you provided we really can't help you.

One more addition. As the proposed modern error cluster could hold multiple errors simultaneously, the catch nodes need to be able to catch multiple errors if there are more than one errors of the same type. Perhaps the catch function could simply return array of objects of user specified type instead of a simply single object. Alternatively the same node needs to be revisited as many times as errors of the type are no longer found. This could be alternatively achieved if the modified stacked sequence could have a revisit frame input terminal at the inner side of the right end. There may be other shortcoming as I haven't thought of this concept too deeply. This discussion is somewhat related to an earlier discussion here at LAVA where I submitted an example how to thorw and catch errors using the error cluster. Tomi

Thanks for the correction By the way, Cluster to Array and Array to Cluster primitives may be handy when you need to build the inner cluster of 32 elements.

No, I don't want to know anything about icon indices. I just would like to add a new item to the tree and specify that this item icon is defined by this image data and the tree control would check if that icon is already used in the tree and if not then add it to one of the icons and then set the icon index of the current icon properly.

My guess is that you cannot do it via LabVIEW. The best suggestion I can give is to use dialog windows to mimic context menus. I've to face this same problem in a few weeks as I'd like to activate the context menu when user clicks the left button, not the right one. Tomi

Yes, I think it should work that way. Clusters are passed as values or pointers depending on if you use "handles by value" or "pointers to handles". You need to do some typecasting within LabVIEW to transform between the inner clusters of U8 and some LabVIEW type before and after the library call. Tomi

You misunderstood me. The elements in a tree can have icons in a similar way as each item in LabVIEW 8.0 and later project explorer has icons. The addition of icons using the property nodes is somewhat complicated and therefore it would be nice if there was a simple way to specify an icon of an item. BSD license would be super! I think crelf and Jim Kring agree with me on this.

You can use U32 for any kind of pointer in a 32 bit operating system. U32 value 0 means NULL pointer. However you cannot preallocate memory to the location your pointer refers (unless you call memory manager functions in LabVIEW.exe). So pretend your function interface was: unsigned long fftw_plan_dft(...) // allocates memory block .. fftw_execute(unsigned long p) // uses memory block .. fftw_destroy(unsigned long p) // destroys memory block