-
Posts
4,850 -
Joined
-
Days Won
292
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
Isn't the array intersection the result of the terms present in both arrays? You show the list of terms that are present at least in one, not both.
Indeed. It was a quick demonstration of a theory rather than a solution. If you change it like so......
Then you get unique intersection values for example.
There's no need to concatenate in a loop at all here. You know in advance that the intersection array cannot be larger than the smaller of the two input arrays, so you can preallocate an array of that size. Track the current array index in a shift register. Each time there's a match, use replace array subset instead of build array, and increment the array index. When the loop finishes, resize the array to the final value of the index shift register. This is much faster than concatenating in a loop.
Sweet. that'd be even faster
-
I thought I'd seen this problem bedore
Here is another method that's similar to your first one rather than the second. This VI (wrote it a while ago now) returns the array differences but the theory is the same.
Slightly different in that it actually does a search and eliminates data, therefore reducing the data set as it goes. Its very quick especially if the duplicates are sparse and isn't explicitly linked to the data-set size, rather the number of duplicates.
-
Array indexing inside a for loop is a killer. Actually concatenating isn't too bad due to optimisations (LV is very efficient with For-loops). I vaguely remember a challenge from Jim Kring to find a better method than concatenating for selecting arbitrary values from an array. I don't think there were any takers.
So assuming that we have to concatenate in some form or another the best we can hope for is pre-processing. Along this line what about finding turning points? Maybe faster, maybe not but it would uses in-build functions (generally faster than native LV) and eliminate the array indexing.
-
Hi all,
I've took a look at this and it seems, as far as I can see, the "NI implementation" is quite more complex due to the execution on RT target. SQLiteVIEW only needs sqlite3.dll (or .so for linux OS) to run. Our toolkit also provides way to improve query execution performance using statement features and we have lot of other useful features to add to improve the end-user development experience.
Stay tuned to evaluate our toolkit for free. We are looking forward to know your feelings about it.
Regards
Actually I would say the opposite..... Its too simple
But probably sufficient for most users. Why they went for an intermediate "wrapper" dll is beyond me. I guess NI has more C programmers than LV programmers nowadays (or maybe just lazy to implement the switching in LV). But the wrapper is only half a page (excluding comments, spacing) basically just opening, preparing and executing the SQL.
The fact that it supports RT targets isn't that complicated (conditional disable structure). But it overlooks a lot of DB functionality (parametrised queries for example).
I would ignore the RT targets at your peril. This is the only viable database solution available for RT and (IMHO) why most LV users are interested. And, as I intimated earlier, all you need is a conditional disable and a DLL compiled for the targets (that's where most LV users will come up against a brick wall if they want to "roll-their-own") . There are many FREE db solutions for windows and linux (don't forget MAC too)
You might also consider providing a "drop-in" replacement for the NI Database Toolkit to allow users to easliy switch/update to SQLite. Nothing sells a product quicker than an easy upgrade path
If your engineers are suggesting an implementation in .NET. Slap them for me please
-
OOP as in LVOOP as in LabVIEW OOP?
Hope you're pronouncing that correctly
-
Nope, its a LabVIEW thing
Nope. Its an OOP thing
-
I just figured the sound for audio recordings would not be as good as a PC Headset?
yer.. sure...
Sound isn't maybe as good. But that's what I've got a 200W stereo for
Mic isn't bad, fine for yahoo, skype, voice chat etc but not studio qualty. Don't forget they are heavily compressed and filtered to reduce bandwidth so even with a studio mic your gonna sound crap.
-
I use my phones bluetooth headset . Had it about 3 years and its the only mobile headset that stays in my ear Good range. Good quality. Good volume. Can't fault it for general purpose. Works with everything.
Movon MF120 http://www.prepaymania.co.uk/mobilephone/generic-movon-mf120-bluetooth-headset.html
Mine ISN'T pink by the way...lol.
-
Thanks. I should hang around LAVA more often.
Naaah. You probably have a real life
-
I want it now!
Then take a look at this
-
-
Holy cow people! Was this international insomnia day/night? I know at least some of you are based in North America...
Anyways, neat stuff!
I'll get all the sleep I need when I'm dead. (might be sooner rather than later though.)
-
In the VI settings.....
If you need to close the first vi then you will need a different method. You can either just hide the first VI's panel or you can launch the second VI dynamically
-
If you want. You can easily add error prioritising to your error handler (then you can handle critical errors, warnings etc,etc).
-
OK. I think its transparency. If you select the paint-brush tool and right click on my example that works and then change the background colour to T. It will also not work.
-
Well. I've been through about 20 gifs. About 50% of them work. But I have found out that gifs that work in Labview don't work if I post them in here.
-
That's whacky ShaunR!
What type of image is that? Is it an animated gif? I can see that it works but when I replace your image with my animated gif it doesn't work. So all I can think of is your animated gif is a different format.
Yup. An animated gif. That's about all that windows tells me. I don't know what type or version. Yours doesn't seem to work on my machine either. Hmmmm. Now I'm really interested
-
The problem is we are pretty much stuck with the controls we are given. As we don't have access to the control canvas and the "OnRedraw" event, we cannot change the control (with the exception of a few cosmetics). Everything we do to get around it is really a kludge and not for the faint of heart.
You are probably better off finding an Active X or .NET control tat supports images and using that.
-
(I would still like more options tho - status bar, status text etc...)
Thats because I can't get this to work. Ok, so I must be doing something completely stupid?
If I set Visible = FALSE first then Defer = TRUE the gif does not show until I set Defer = FALSE
If I set Defer = TRUE first then Visible = FALSE if only updates when I resize the window.
<object id="scPlayer" class="embeddedObject" width="841" height="502" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2b81030a-c431-43c2-b553-967c8e470db3/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2b81030a-c431-43c2-b553-967c8e470db3/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2b81030a-c431-43c2-b553-967c8e470db3/FirstFrame.jpg&containerwidth=841&containerheight=502&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2b81030a-c431-43c2-b553-967c8e470db3/Defer%20Panel%20Updates.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/2b81030a-c431-43c2-b553-967c8e470db3/"> </object>
Can you or Francois post code?
Try this.
-
Ok, (as I posted above) I assumed differently, a quick test confirms that I was wrong, so that is good.
I can do as per your example but I would still like to see something (i.e. throbber, status bar etc...) moving on the panel though.
As a test I loaded the entire C:\ directory into a Tree it was taking minutes.... (I didn't wait for it to finish)
So in this case, I would really like my user to see something moving during this time.
I would very much like to keep it simple, but I workarounds aren't i.e. sticking the Tree in a subpanel OR having a VI overlayed (what if the user wants to be move the screen? O will have to synch both VIs) are currenly my only options? Unless there is a method for defer Tree updates I haven't seen? If not this would make a good Idea on the Idea Exchange IMHO.
Doesn't get much simpler than an animated gif that is visible or not
-
[You changed your post]
But Google and IE were just giving me static images.
Hmm, maybe I could put the e.g. Tree in the subpanel?
Defer updates on the subpanel and the parent-VI can do what it wants?
Too quick...lol
http://www.screencast.com/users/Phallanx/folders/Jing/media/6d76d3b1-a19d-4657-8db9-35caa09e1fa4
-
Ok maybe a stupid question?
How do I get a gif on the FP.
Drag and Drop not supported.
Import picture to clip-board. then paste.
-
Also saw a slick demo at the last NI week that had a VI grey out when it displayed a modal dialog box. Pretty sure it was done with a simple image overlay using the alpha channel. Not sure if it was as simple as toggling visibility, or if it involved moving the image from an off screen location, but it looked really slick.
I quite like making the vi a little bit transparent (say 5-10%) it really brings the focus to the dialogue and is dead easy.
But I'm +1 on disable and greying out controls.
-
BD >>> Right Click >>> Programming >>> Structures >>> Global Variable
Ben
Project>>New>>Create New>>Class .
Its quicker
64-bit scripting in 32-bit environment
in VI Scripting
Posted · Edited by ShaunR
I have 3 machines at home. 2 are x64 1 is x32. One of the x64s has both x32 and x64 labview. I don't have any problems switching between OSs or labview. But there are some things to bear in mind.
32 bit dlls will work on a 64 bit machine, but you can't use LVx64 (must use LVx32t)
x64 dlls won't work at all on a 32bit OS. (you will get load errors if you try to use LVx32 to load them). Likewise 64bit applications written in LV will not work on a x32 machine.
LV must recompile between x32 and x64 every-time you load (the whole hierarchy) which might be a bit of a nightmare for your source control if switching to and fro.
Editing with LVx64 on a x64 OS is like lightning. LVx32 runs like a slug. Anything pure labview (like scripting) is totlay interchangeable. Install BOTH