Jan Klasson

Hi, First about inheritance vs. containment. I like to use inheritance in the way that objects from child classes are exchangable. To do this the public methods of the parent class must make sence and be possible to override in the child classes. It is unlikely that this will work if the classes in the inheritance hierarchy represents totally different "things". Truck inheriting from Vechicle would make sence since a truck "is-a" vehicle. But the Truck inheriting from Gasoline seems weird. And Vehiecle inheriting from Gasoline or vice versa also seems weird. Those classes are different abstractions. About the session data field in the Vehicle parent class. I don't know what kind of code you need to handle the session but let's assume you put it in a separate class to use containment. Then you let Vehicle contain this class in one data field. This may be good from a design perspective (I couldn't tell without knowing more about what you do) but it doesn't solve the issue that you find annoying, i.e. child classes has to use a get method from the parent class to read out the object... back to square one:-). Here is one way of solving the case with scenarios repeating in child class methods. For each dynamic dispath VI in the parent class create a static "mirror" method. The static method should be public and work like a "macro", in this case GetSession-call the DynamicDispath VI to do the job-CloseSession. Let's say you like the vehicle class to have the dynamic dispatch vi "StartEngine". Make this VI protected and call it StartEngineImp. Then create a static method and name it StartEngine (in the Vehicle class). In StartEngine you first read out the session, then wire it to StartEngineImp, then close the session (if needed). Child classes Truck/Car should create overrides for StartEngineImp. This scenarion will double the number of methods in the parent class but you will not have to repeat scenarios in child class methods. If it is worth it only you can tell. There may very well be smarter ways of doing this, please let us know. I haven't really tried it in LabVIEW but I believe it should work.

QUOTE(crelf @ Sep 13 2007, 10:11 PM) To read more about the tool and the GOOP 3 check out the tool manual online: http://www.endevo.se/files/downloads/products/gds/ View the section: GOOP 3 Provider and also OpenG Provider. About licensing. The restrictions for the free Community Edition is exactly as Chris listed in a previous reply. The license allows commercial use, it does not restrict the usage compared to the Professional (non-free) edition. It is only a functional limitation and no Endevo support. Jan Klasson Endevo

Here are some serial classes I did in prehistoric time (probably LV 4). Attached is a png describing the design (as I recall it). The Serial class configures the serial port at object creation (this was a by-reference class so there was a Create method). Send - sends the message string, Receive - makes a blocking call to the serial port driver and wait for data to arrive. The InputStream and OutputStream packed/unpacked the messages received over the serial bus. A custom application protocol was used. The InputStream -Subscribe allowed client objects to subscribe for various messages by name. InputStream:Read - returns the latest message InputStream:Process - a process VI running in the background. It calls Serial:Receive and waits for message strings to arrive. When a string is received the Process method unpacks it into the application protocol message data structure. Thereafter the message is distributed to all subscribers of that message. OutputStream:Write - takes a message data structure as a parameter, packs the message into a string and adds it to the internal send queue (attribute "msgs"). OutputStream:WriteContiuousMsg - adds a message which is to be repeated with fixed intervals, otherwise it does the same job as Write. OutputStream:Process - Executes periodically to ensure the continuous and non-continuous messages are send. Calls Serial:Send to send a string over the serial bus. I guess the main point of the design is that it separates two protocol layers. The Serial class encapsulates the serial bus driver and sends/receives strings. The InputStream/OutputStream encapsulates the application protocol, these messages where described with a type def. Jan

QUOTE(orko @ Aug 24 2007, 09:32 AM) I agree, training is essential. We, Endevo, have re-written our two day course (which have been run since -98) to introduce OOP in LabVIEW, lvoop as well as by-reference extension is covered. We are currently writing the last words in the course book... It will be made available this Autumn and we are working on having it made available for as many LabVIEW programmers as possible. At the least it will be available through: Endevo in Sweden and Australia VI Engineering in the US Zühlke in Switzerland/Germany And anywere you can convince me to travel (which is WW). Jan

Orko: Is it the .se domain your "silly firewall" don't allow access to? Jan

First the downloads: The download page I referred to (http://www.endevo.se/content/view/18/20/lang,en/) has links to the download zip files: http://goop.endevo.net/GDS/GDS_v1.0.0(P1Y).zip (for LV 8.2.1) http://goop.endevo.net/GDS/GDS_v1.0(LV85).zip (for LV 8.5) It is the same installer for trial (of professional), community edition, and professional edition. It is the license key which controls what features are accessed. The trial is for the professional version without any limitations of functionality. The professional trial will automatically downgrade to community edition after a month. You can contact Endevo (sales@endevo.se) for prolonged trials. Community edition is not time limited. The key: COMM-UNIT-YEDI-TION-2007 is valid through 2007. By the end of this year Endevo will provide a community key for 2008 which will require a reactivation, we will continue to provide a community edition for as long as we support the tool. The reason we timelimited the key is to track to what extent the free tool is actually used. To read more about the tool and the differences between community and professional, pricing etc visit our home page: http://www.endevo.se/content/view/109/107/lang,en/ You can also browse the help manual on-line: http://www.endevo.se/files/downloads/products/gds/ The community edition is limited in the following ways: It does not support the Endevo GOOP 3 class architecture. Maximum number of classes in a project is 10. There is no support. There is no update class to latest class template feature. Using the community edition you can create standard LV classes from a class template as well as methods from method templates. You can also create the OpenG extension of the lvclass which provides by-reference behaviour (based on LV Queues). These class templates are BSD licensed open source and provided through OpenG. They are developed by Tomi Maila with our blessing and deep gratitude. The Endevo GOOP 3 class model (only in professional) also provides by-reference behaviour and it is built upon the lvclass. The object kernel is shift register based and it is basically the same as the predecessor GOOP 2 which has been used since 2003 (thousands of classes hs been created using this class template). Very much proven by use in other words. The tools has numerous features but in short: - It is integrated in the LV project environment - It allows you to choose between, lvclass/OpenG and (in professional) GOOP3 - It creates classes from class templates, manages icons, and stores files to disc. - You can create methods from method templates (read/write method etc), override methods, getter and setters which reads/writes class data fields. The tool manages method icons as well. - OpenG and GOOP 3 classes has a debugger - You can rename or clone classes or change inheritance. The tool handles re-linking, renaming and icons. - You can edit class wire appearence and the class glyph in the project explorer. Pricing GOOP Development Suite v1.0 - Professional: US$800 or EUR600 or SEK5630. We will soon provide a new version of our UML tool which integrates with the GOOP Development suite and provides round-trip engineering for all three class models. Code generation, reverse engineering and synchronization. We are planning for a community edition of the uML tool but haven't settled the features of that yet. Thanks, Jan

Hi, If you tried installing the Endevo GOOP Development Suite v1.0 on LabVIEW 8.5 you have noticed it doesn't work. :headbang: We have fixed this and there is now an installer available for LabVIEW 8.5. :thumbup: The installer for LabVIEW 8.2.1 is not affected by this update. Download the installer from: http://www.endevo.se/content/view/18/20/lang,en/ The installer is the same for the (free!) community edition as well as for the professional version. Enjoy! Jan Klasson and Mike Holmström Endevo

Hi, If you tried installing the Endevo GOOP Development Suite v1.0 on LabVIEW 8.5 you have noticed it doesn't work. :headbang: We have fixed this and there is now an installer available for LabVIEW 8.5. :thumbup: The installer for LabVIEW 8.2.1 is not affected by this change. Download the installer from: http://www.endevo.se/content/view/18/20/lang,en/ The installer is the same for the (free!) community edition as well as for the professional version. Enjoy! Jan

Hi all, I am happy to inform you that Endevo has released a new generation of GOOP tool for LabVIEW 8.2.1 - The GOOP Development Suite v1.0! It supports three (!) different class models: - native LabVIEW by-value classes - Endevo GOOP 3 - adding the by-reference model to lvclass - OpenG class templates (developed by Tomi Maila, read his post) - a LabVIEW Queue based by-reference model for lvclass Fully integrated in the LabVIEW project environment. Icon editors. User definied class and method templates for all three class models. Visit http://www.endevo.se/content/view/109/107/lang,en/ an read more. Free trials and a free Community Edition. Hopefully the only GOOP tool you will ever need:-) Jan Klasson and Mike Holmström Endevo

Hi all, I am happy to inform you that Endevo has released a new generation of GOOP tool for LV 8.2.1 - The GOOP Development Suite v1.0! It supports three (!) different class models: - native LabVIEW by-value classes - Endevo GOOP 3 - adding the by-reference model to lvclass - OpenG class templates (developed by Tomi Maila, read his post) - a LV Queue based by-reference model for lvclass Fully integrated in the LabVIEW project environment. Icon editors. User definied class and method templates for all three class models. Visit http://www.endevo.se/content/view/109/107/lang,en/ an read more. Free trials and a free Community Edition. Hopefully the only GOOP tool you will ever need:-) Jan Klasson and Mike Holmström Endevo

To clarify: the Endevo UML Modeller 1.1 supports reverse engineering of UML state diagrams from LV state machines or queued message handlers. Compared to the NI state machine toolkit the Endevo solutions does not enforce a certain code template to be used for this feature to work. Of course, this makes code generation a bit cumbersome, but who knows... code generation from state diagrams is on the wish list, but on the top right now is adapting our toolkits to the LV native OO. Therefore state machine improvements will have to wait. Jan

To add material to the discussion I post another design pattern. If you want to separate the by-reference semantics from the class, this is one way to do it. I have implemented a separate container class: ObjectRepository. It has the ability to store any LabVIEW Object. The idea is that if you want to use a class by value you don't need to do anything. If you want to store the class by reference you create an instance of the ObjectRepository. On the up side: - Separetes the class from the way it is stored or handled. - The ObjectRepository can be used for any native class without adaptation On the downside: - Explicit downcast is needed when you read the object from the ObjectRepository since it returns LabVIEW Object. It has a potential for run-time errors. Without templates we cannot create generic type safe containers. - Code readablity; to pass the object by reference you actually wire an instance of the ObjectRepository. - Probably more, haven't spend too much thougth on it. Disclaimer: There may be some flaw in the implementation, it was a quick hack to show an idea. Jan Download File:post-2808-1156330697.zip

Some more GOOP info... The only OO support for by-value is the native OO. All external implementations you listed provides by-reference semantics. NI implemented the feature we couldn't provide externally. In addition to the listed GOOPs there is the free GOOP Wizard 1 download from NIs site (developed by Endevo-NI). The run-time repository is based on a CIN node and object data is streamed. Endevo GOOP Wizard 2 is a better tool (icon editors, class renaming etc) on the same GOOP architecture. About the Endevo GOOP Wizard 3 (which I know best for some reason): You will find better run-time performance for object data read/write in object repositorys based on Queues or un-initialized shift registers. Endevos GOOP Wizard 3 (with inheritance support) is based on un-initialized shift registers. Inheritance is nothing without virtual methods which is provided by Endevos Wizard 3. These provides the same behaviour as the Dynamic Dispatch VIs in the native OO. But we implemented them using VI server which actually turns sub classes into potential plug-ins. There is also protected attributes (meaning attributes can be inherited from base classes). And also a concept we call Class Attributes (aka static attributes/data), this is attributes belonging to the class so it is used for data to be shared by all objects of a class. There is also the G++ from the German company Vogel Automatizierung but I am not sure if that is around any more. Jan www.endevo.se Shameless plug: The Endevo UML Modeller is the only UML tool with code generation and reverse engineering for LabVIEW. It currently supports only Endevos GOOP.

I wanted to comment about overloading (allowing same VI name and different conn panes) beeing necessary when inheritance is used. I don't agree. What is necessary is virtual methods, or as NI call them Dynamic Dispath VIs and these are supported. If you need different input/output types you can create different methods. Ok, it is not as neat but it is also less error prone since you know which method gets called. My second comment is about the native OO solution should be good for beginners. I don't agree. The reason is that when you start using a new technique like OO you like to apply it where it makes most sence and where you see the most obvious need. I believe that is typically the instrument control for the LabVIEW programmers. Creating nice abstractions of data is secondary and more advanced. The problem is that instrument control is where you probably are most likely to prefer by-reference. Therefore the OO beginner will think that the native OO doesn't make sence - it doesn't solve the major use case. Time will tell, but that is a risk I see. As regards the constructor issue. I agree very much that support for structured initialization is needed. The problem with a constructor in LV is that front panel objects are created when the VI is loaded and that may not me the time it makes sence running the constructor code. For the current solution I think a class template for a structured Init, especially to handle inheritance (allowing different parameters on each level), would make sence. It requires a tool for smooth creation/maintenance of classes though. /Jan

Yes, I also think many important use cases for OO also requires by-reference. In your example with parallell loops accessing the same data instance by-value makes no sence. Or for instrument control I would probably prefer having control of when objects are created. But I also think there many cases where you could benefit from the flexibility that classes and inheritance could give and it does not really cause any functional issues in the design that objects may get copied. For example you may like to read the same kind of data from different sources, first your input data comes from an Exel file and then you upgrade to XML files. This could be solved by using inheritance and sub classes for each file format making it possible to add new file formats without braking or modifying existing code. Jan www.endevo.se

In the Endevo GOOP (GOOP Wizard 1, 2 or 3) you use the "new" VI to retreive the ref from a string name. If you are using openG it probably works the same. Jan Klasson Endevo