brian175

DOUBLE POST- sorry I should have searched first and posted second. This has already been discussed here:

I found some code that I had written years ago and had since forgotten about, but it does exactly what is being discussed in this topic. In the included zip file is Example.vi, Diagram below. To use in your own diagram, drag HighLightExecution.xnode. I originally wrote this to test using xnodes for quickly changing block diagram function. The attached code is in LabVIEW 8.2.

HighLightExecution.zip

QUOTE(Aristos Queue @ Feb 8 2008, 02:51 PM)

a) I haven't looked at your test code at all yet, but something really smells about the LVVariant speeds because this is something I've benchmarked many times and it has a pretty nasty growth curve*. Staying constant for creation between 1000 and 2000 is pretty close to completely unexpected.

b) Did you use Jason Durham's revised version of the Map that has the AVL balancing code? If not, please see the very first post in this thread which has been edited to have both my original and his modified version. Without the tree balancing, it would be easy to get some pretty nasty times (as I said in my original post).

c) If you are using Durham's version, then there may be one other problem. Do you insert random keys or keys in some already sorted order? The worst case scenario for the tree balancing is going to be inserting already sorted information into the tree -- you'll trigger the tree balancing code A LOT. There's an optimal insert order if your data is already sorted to avoid the tree balancing, which is to start by inserting the middle element of your list, then the middle element of each of the halves, then the middle element of each quarter, etc. ANY map implementation has situations in which its performance seriously degrades, and almost all of them are optimized for random key inserts.

*as of LabVIEW 8.5... I have long hoped that someone would improve the performance of this method, and I heard someone might be working on it for future LV version.

a) It seems like the results are the complete opposite of what you expected

b) I did use the revised version

c) The keys were already sorted, but when I create random keys the results are the same

Download File:post-987-1202569102.vi

Download File:post-987-1202569109.vi

QUOTE(Tomi Maila @ Nov 9 2007, 05:21 PM)

Hi guys! Great job adding balancing algorithm to the tree!

Now that we have a balanced in-place OOP map for objects it's feasible to ask how does this tree perform compared to LabVIEW build-in map namely variant attributes. To my experience variant attributes peform well. They accept any data type and not oly LabVIEW objects. So the question is, if there is actually some real reason to use this LVOOP implementation of map instead of variant attributes. Is this implementation perhaps more memory efficient for LabVIEW objects? Has anybody done any testing?

Tomi

- Is having a headache after 12 hours of XNode development.

QUOTE(Aristos Queue @ Nov 10 2007, 07:59 PM)

How much do you want to bet? I haven't gotten the chance to look at the code or review this lengthy post but here are my testing results and VIs:

LV Class Map: (time in ms)

Number.......Create........Fetch........Delete

100................341............5.............3

1000............49532..........85...........14

2000...........240160........182...........26

LV Variant:

Number.......Create........Fetch........Delete

100.................2.............0...............0

1000..............38.............2...............1

2000..............39.............2...............2

Download File:post-987-1202386557.vi

Download File:post-987-1202386565.vi

Brian

(Is there a way to insert a table into a post? Extra spaces seem to be removed)

QUOTE(brian175 @ Jan 17 2008, 10:31 PM)

The zip file is here

Sorry, try

http://www.dataact.com/downloads/dqGOOP/dqGOOP-1.0.2.612.zip

QUOTE(crelf @ Jan 17 2008, 08:36 PM)

For some reason, the DataAct website keeps crashing my IE7 so I can't get a hold of them. I've been able to limp through and download the installer, but it only installs a few startup shortcuts (I'm using LabVIEW 8.2) - when I run the installer the "dqGOOP" selection is unchecked and disabled, so I'm struggling to install it.

Can anyone help? Or, at least, let me know how ot get in contact with someone at DataAct without having to go through their website?

Did somebody call? Our website hasn't been the same since our web host upgraded to PHP 5 and I haven't had the time to fix it. My quess is that the installer hasn't been updated for the later versions of LabVIEW so you have a couple of options.

1) install into an older version of LabVIEW and copy the directories and files from the project directory or

2) try the zip file which was created for the non-Windows users.

The zip file is here

I am actually working on dfGOOP which is a framework that uses LabVOOP but allows for "by reference" OR "by wire" and switching between. I am in the process of converting the DataAct Icon Editor from dataFOOP to dfGOOP.

If you need to get of hold of me, just send a PM

Brian

QUOTE(Jim Kring @ Aug 21 2007, 11:11 PM)

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

I have added 3 RCM options

1. Disabled - removes all code from the block diagram (should be able to call through scripting)
   
2. Replace With Probe - this ONLY works for error cluster data type now, but replaces the xnode with a probe. the next step is to dynamically build the probe with the correct data type (which is stored in the state). The execution highlighting can be turned off and on by toggling the custom button http://forums.lavag.org/index.php?act=attach&type=post&id=6751
   
3. Clear Highlight Execution - removes the xnode and repairs the wire
   

View of "Disabled" code

http://forums.lavag.org/index.php?act=attach&type=post&id=6752

Updated code

http://forums.lavag.org/index.php?act=attach&type=post&id=6750

I haven't tested this too much so I wouldn't actually use it, but it could be developed further.

Brian

QUOTE(Jim Kring @ Aug 21 2007, 11:11 PM)

Thanks, Brian. I think that a custom probe would be preferable (over an XNode) since it does not modify the code. But, in order to create a "universal" probe you would have to create a VI for every possible data-type (ugh).

I was thinking that it should behave more like a breakpoint and should be able to be saved with the code. I haven't done it yet, but I believe that you could code the the HighLightExecution node to remove itself and "repair" the wire that it is on with a RCM "Clear Highlight Execution Point". I would also like to determine if the node is dropped on a wire and automatically "wire" itself in.

If a custom probe was needed, you could create a few for common data types (error, boolean, numeric,...) and that would work in most cases. Then at worst you would have to add a boolean constant and wire to a structure in order to use the custom probe.

QUOTE

Unfortunately scripting won't help here since the data type must match statically. Although, it would be possible for an xnode to create a custom probe based on the wire type. I could add a RCM "Generate custom probe" that would create the custom probe that would work for the wire type currently attached.

QUOTE(Tomi Maila @ Aug 21 2007, 10:45 AM)

Actually when I ran the 'LAVA tryout' installer after having installed 8.5, it only had installation options for LV 8.2 earlier. I meant if the installer will support 8.5 as well. I guess I can simply copy the files to 8.5 but I didn't try it Of course it would be nice to have all the new properties and methods supported as well

Tomi

For now I would just copy the entire DataAct directory from the 8.2 (or 8.0) ..\LabIVEW\project directory to the 8.5 one. I will add updating the installer to my list.

QUOTE(Jim Kring @ Aug 21 2007, 06:05 PM)

I just heard through the grape vine that this error message will probably be "fixed" in a future version of LabVIEW. So, faking the execution state to avoid the error message is probably safe.

Here's a version with better error handling.

http://forums.lavag.org/index.php?act=attach&type=post&id=6705

http://forums.lavag.org/index.php?act=attach&type=post&id=6704

The "Help" for the Fake Execution State Method only lists valid values as 1 - running and 2 - stopped so I would be careful in wiring the actual state back to the fake state. The help for the scripting props and methods are displayed in the DataAct Class Browser

Since there has been much support for this feature, here is an xnode that performs the task in a LabVIEW native way.

1. place the HighLightExecution.xnode on the block diagram

2. the xnode can be placed on any wire (the input terminal is wired directly to the output for flow control only)

3. click on the xnode to toggle between execution highlighting on and off

Open the "Example.vi" to see it in action

There are many possibilities for enhancements such as using the wire in for a conditional on (similar to custom probes), but this is a good start for now. I'm sure I sould add some additional abilities for copy and pasting, but it seems to handle it without.

http://forums.lavag.org/index.php?act=attach&type=post&id=6706

QUOTE(Tomi Maila @ Aug 21 2007, 10:17 AM)

Hi Brian,

Are you planning to make a LV 8.5 version of this tool?

Tomi

Yes, but the question is when can I get around to it. The current version should work on 8.5, but I assume you mean to add any new classes/props/methods available in 8.5? The process is mostly automated, but unfortunately there is still one very time consuming step of verifing that props and methods are assigned to the correct classes.

Brian

QUOTE(Jim Kring @ Aug 20 2007, 09:23 PM)

Here is an example VI (saved in LabVIEW 8.2.1) that attempts to enable execution highlighting on itself. If you run it, you will see the aforementioned error.

http://forums.lavag.org/index.php?act=attach&type=post&id=6695

http://forums.lavag.org/index.php?act=attach&type=post&id=6694

This works, but it may cause more problems since there doesn't seem to be a way to turn "off" the fake execution state. I guess that the best way would be to set the fake execution state back to 1 (running) since the VI is actually running?

http://forums.lavag.org/index.php?act=attach&type=post&id=6702

Ton,

Thanks for this. I was hoping for something with a little less extra baggage (VITs, etc.) I'm working on OpenG Builder and I'm coding in LabVIEW 6.1 and I need to set an Application Property in LabVIEW 8.2. The current solution is to make dynamic calls to a VI that is written in LabVIEW 8.2 that calls the specific property in property node.

Thanks,

-Jim

I have the same issue for many of our applications/toolkits and had been doing the same thing. However, for our Icon Editor I have tried something new, let the installer do the work for you. The installer (or Package Manager) will install the 6.1 code (in your case), then detect the version of LV and write over specific files with replacement files of the same name but written in another version of LV.

I am looking forward to an update to the Builder! I will review my 8.0 and 8.2 modifications and see if there is anything I should let you know about.

Brian

... Is there any list of all the possible abilities?

Here is the complete list -

State, AdaptToInputs, AugmentSelf, BuildMenu, BuildMenu2, BuildMenu3, CalculateFeedthrough, CanAcceptDataDrag, CanAcceptDataDrag2, Compare, Copy, GenerateCode, GetAutotoolRegions, GetBounds, GetDataForDrag, GetDisplayName, GetDisplayName2, GetErrors, GetErrors2, GetErrors3, GetGrowInfo, GetHelp, GetImage, GetTerms, GetTerms2, GetTerms3, Initialize, Message, MessageWithUI, MessageWithoutEffect, MessageWithUIWithoutEffect, ModifyCode, MutateForPrevious, OnDataDrag, OnDataDrag2, OnDoubleClick, OnDrop, OnFontChange, OnOperateClick, OnRefeeChange, OnResize, ReplaceSelf, SaveForPrevious, SelectMenu, SelectMenu2, SelectMenu3, SpecifyInsertTerm, UpdateState, UpdateState2

The reason for the BuildMenu, BuildMenu2, and BuildMenu3 is that the first and second are depreciated, so you should always use the latest (if you look at the ability VIs you can see that the cluster data has changed.)

Here is a another place to get Ability VIs:

..\LabVIEW 8.2\resource\Framework\Providers\xi\xnode.llb

However, beware that the connector panes may not be correct. The first and only one that I looked at was BuildMenu3 and it has a different connector pane than ones in use such as:

..\LabVIEW 8.2\vi.lib\variable\varXNode.llb\varXNode_BuildMenu3.vi (which is not password protected)

Warning this VI will crash LabVIEW

Download File:post-987-1169247482.vi

I started to play around with adding a new ability VI to an existing xNode library but it so far has only caused crashes.

Brian

I've been unable to get to the DataAct website for a couple of days now. The domain name hasn't expired, but the DNS doesn't resolve. I'm hoping this is temporary. Does anyone know?

Our hosting company is claiming that they are having problems with their DNS servers and that they are working on a solution. I wonder if they will still claim 99.9% uptime? Its a real PIA though, since anyone sending us email is getting bounced as well.

Is there something specific that you needed from the website?

Thank you guys, that solve my problem!

just one other thing, what are you VI Data Act? Are those VI that you created? If not, where can I find them?

Thank you,

The screen shot that I posted above was from an application that we developed that made extensive use of the MS Jet Engine. One of the more powerful features is the built in replication. The screen shot below shows some of the other utilities that we used.

And no it isn't possible to upload these VIs since they are currently part of a much larger application

Hello there,

I'm trying to find a way to compact a database with labview. I've look for an ms access 2003 activex, but I didn't find it. Does some know how to do it?

Thank you,

coolaid

Here's a screenshot of a VI that performs the compacting. Basically you have to manually create the temp file and then replace the original by deleting it and renaming the temp.

Step 1: List LabVIEW classes and generate the hierarchy **DONE**

Step 2: Update DataAct Class Browser which allows creation of Private and Scripting Classes, Props and Methods **In progress**

Step 3: Cool applications that make use of the private and scripting API (Maybe even one that creates LabVOOP classes)

Step 2 is now complete: View this topic

"Dynamic Generation of Labview 8.2 Class Hierarchy" -- I thought you'd built a tool for generating LabVIEW classes. You know, as in XYZ.lvclass.

I'm going to go be depressed now. The adrenaline rush followed by crash is too much.

Step 1: List LabVIEW classes and generate the hierarchy **DONE**

Step 2: Update DataAct Class Browser which allows creation of Private and Scripting Classes, Props and Methods **In progress**

Step 3: Cool applications that make use of the private and scripting API (Maybe even one that creates LabVOOP classes)

Does anyone have an idea where the LabVIEW 8.x version of the Private Class Generator is? I've looked everywhere I can think of or search for. Maybe I'm just working on reduced capacity today because I am still on coffee #1 and it is after lunch.

Here's a link to the 8.0 Version

Here's a link to the new 8.2 Version

I am working on updating the DataAct Class Browser so I thought that I would update this as well. This is a modified copy of PJM's code from this Topic.

This version uses a template instead of creating a new VI and objects for every iteration, theoretically it should be faster.

Brian

Download File:post-987-1167763756.zip

Brian and Jim,

Thanks. I try these out tomorrow, it's getting late here. Did you try if your solutions work if the class is embedded into a library i.e. the name is something like this: MyLib1.lvlib:MyLib2.lvlib:MyClass3.lvclass?

Yes, the type string contains the full Library path (TestLibrary.lvlib:TestClass.lvclass) so just add ":TestClass.ctl" and Open VI reference works just as before.

But you don't know the path to the class by just knowing the in memory name. And there is not such a scripting property I know of that would return "All Classes in Memory". Of course you can get "All VIs in memory" and then try to figure out which class each VI belongs and store them to some sort of set of all classes and then you can compare your class agains all the classes in the "set of all classes"... well complicated. Anyhow for my purposes I just would like to use the class name in a indicator that would be able to show at least some information of all the classes...

Hmmm... there is this probe for objects. I wonder if it's implemented in pure G and if the block diagram is not locked...

Jim is correct the type string and the data string both just contain the class name (which can easily be extracted). To get a VI reference, just build the private data cluster (which must be in memory). My example is "TestClass.lvclass:TestClass.ctl". From here you can get the path and even the private data cluster.

Download File:post-987-1165272751.vi

Download File:post-987-1165272777.vi

Download File:post-987-1165272895.zip

(*.lvclass extension is not allowed?)

Brian

Here is a version that Doesn't Crash for anyone following this topic and interested in using notifiers in objects

Download File:post-987-1164231546.zip

As for the crashing, I believe that the cause is the fact that the VI strict type def in the class data contains the current class object as an input and output. LabVOOP doesn't allow a class to include itself in it's data.

... Brian, you are left handed, aren't you?

No, right handed

I cannot replicate this. I've tried everything. I've followed instructions verbatim, I've tried variations, I've tried loading without the project, etc. No crashes when I delete - wire - delete - rewire.

1. Open New Notifier Problem.lvproj

2. Right click the Notifier Class.lvclass

3. Select New=>Dynamic VI

4. Switch to wiring tool (I have auto tool turned off)

5. Hover (or click) on object wire

6. Goodbye!

You guys are working in MSWindows right? This isn't a Linux or Mac bug that I'm hunting, right?

Right, Win XP Pro SP2

... Have you used this methods Brian? If you have, have you encountered mystic project corruption or LabVIEW crashes especially when using dynamically called VIs?

Yes and no, No I haven't used that method yet in LV 8.2, I'm just starting to look at OOP in LV 8.2. And yes, LabVIEW will crash if you call a dynamically referenced VI with the Call By Ref Node IF the connector pane that was used to open the VI ref doesn't match EXACTLY the actual connector pane of the VI being called.

I was actually interested in this topic since I have an idea for using Notifiers to keep the object wires synchronized using OOP in LV 8.2.

I got Brian's project to "vanish" (crash without error message) on Friday although I didn't follow Brians instructions. However today I cannot make it vanish even when I follow Brians instructions. Seems like a hard-to-find memory leak bug.

I can still recreate the CRASH everytime!