Leaderboard

I had oglib_lvdata v2.9-1 installed previously (along with all the other old oglibs). The other oglibs updated as dependencies of OpenG Toolkit, but the lvdata did not get touched - though it indicated an update was available so I could easily do it manually.

Using VIPM 2010's Custom Category Feature One of the new features of VIPM 2010 is the Custom Category which, is an easy way to provide a top level category palette for a Toolkit (not just OpenG’s – but your own too!). OpenG decided to use this awesome new feature however, it creates a consequence that I need to point out in case you come across it and think its a bug: When an OpenG 4.0 package and an older package are installed together, two palettes will appear in the Functions (or Controls) palette. Which would look something like this: Being a neat freak this one annoys me but of course this does not create any functional issues - more aesthetic or organisational ones. This is why the OpenG 4.0 release was synchronised. The benefit of releasing Libraries in individual packages is well known however, to minimise this annoyance we released them all at the same time (assuming a lot of users would upgrade at once). This issue was identified early on in the OpenG 4.0 process and we decided that we wanted to incorporate the Custom Category feature and that it would be better to handle it now, as we upgraded to VIPM 2010, rather than later. Previously, the ogsrc_dynamicpalette.ogp package was a dependency of all OpenG Library packages and handled installing all menus etc... Now, each package will create the top level category palette if it does not exist - or replace it if newer, making the ogsrc_dynamicpalette.ogp package redundant (with respect to OpenG 4.0). Anyways, I really like the Custom Category feature

Let's look a bit deeper into the meaning of static and dynamic. Remember text based languages with arrays. Static: Known at built time, e.g. the variable is defined as array[1..10]. Dynamic: Memory is allocated at run-time when the specific operation is executed, e.g. CreateArray(10). In OOP, this maps to the class/object relation. Static stuff is 'owned' by the class, while dynamic stuff is 'owned' by the object, e.g. memory is allocated when the object is created. If I remember correctly, in java I could declare an attribute as static, meaning all instances of the clas (objects) share the same attribute (so they all access the same data space). This is something that isn't possible (?) in LVOOP given the by-val/dataflow nature. Making something static will make the memory footprint smaller, as the data space (both for attributes and methods) needs to be allocated once for all objects, while dynamic methods/attributes need to be created for each object. I've mainly seen the usage of static declarations when there was no 'variable' (attribute) involved, like math functions (e.g. RandomGenerator.ReturnInt() would be static). I've also seen that developers did split their classes into a dynamic 'normal' class and a static class that contained the static methods as a kind of library of helper functions. Ok, that's my share of limited knownledge. Felix

Hi, I am still learning about LVOOP, but here is the little I do know. A static dispatch VI is mostly a regular VI that is owned by the class. A dynamic dispatch VI is sort of "similar" to a polymorphic VI. For each of these VIs, a replacement can be made for each child class. (A class can be a child of a class, of a class, ... etc) If the child class is used instead of the parent class, the "replacement" VI would be used instead of the original dynamic dispatch VI. These replacements are defined by the same connector pane, and VI name. (The owning class name will be different) The connector pane specifies if the VI is a dynamic or static dispatch VI. Right click on the class input/output connectors on the connector pane > "This connection is", and you may choose [required, recommended, optional, dynamic dispatch(required)]. If the dynamic dispatch option is chosen, the VI is a dynamic dispatch VI. If any of the other 3 are chosen, then it is a static dispatch VI. (Both input/output connectors for the class have to agree) An accessor VI is a template for accessing the data from the class wire. This VIs are used as "gate-keepers" to the data. Making them dynamic dispatch allows for different behavior depending on the input class. The dynamic dispatch VIs have a noticeable overhead during execution, and loading. It is always better to use a static dispatch VI unless your really need the dynamic dispatch. PS. Darn....Paul replied first.....lol

Static and Dynamic refer to how the method is called. Suppose you have a Vehicle.lvclass and a Bicycle.lvclass, where Bicycle inherits from Vehicle. If you wanted to add a method on Vehicle.lvclass that behaved one way for Vehicle and another way for Bicycle, you would use a dynamic accessor. Suppose it was ChangeGears.vi.: Vehicle.lvclass --ChangeGears.vi Bicycle.lvclass --ChangeGears.vi You could pass a Vehicle wire into ChangeGears.vi, and if the actual type of the object on the wire were a Bicycle, it would call Bicycle.lvclass:ChangeGears.vi. If it were a Vehicle or any other class that inherits from Vehicle that doesn't override ChangeGears.vi, it would call the Vehicle.lvclass:ChangeGears.vi. Static means you cannot override the accessor, and you only get the behavior defined at the top-level class. This has been (perhaps better) answered here. You can change between static and dynamic by right clicking on the class in and class out in the connector pane and switching from Dynamic Dispatch to Required (for input) or Recommended (for output). - Mike