vugie

QUOTE (laiwei @ Mar 19 2009, 05:00 AM) What type of styles do you want to achieve? You may simply change color and thickness and also gradients if you use "per vertex" color scheme. If you want dashed lines with some extra processing you might be able to cut your input data to dashes. http://forums.lavag.org/post-a11463-3dlines.swf

QUOTE (crelf @ Mar 12 2009, 05:27 PM) QUOTE (Michael Aivaliotis @ Mar 19 2009, 01:52 AM) Ya that would be great. Now back to reality... The "only" thing required for that would be a development environment running on server...

You have to use MoveBlock. You also have to know the total size of this array. Just create Call Library Function node, put "LabVIEW" as library name and find MoveBlock function. Define arguments as usual. As pointer to destination use U8 Array of exactly same size (wire an initialized array to that input). Then you have to cut resulting array to pieces searching for zeros and convert these pieces to strings.

QUOTE (Mark Yedinak @ Mar 11 2009, 09:58 PM) Try calling ImageMagic. In Code Repository you'll also find http://forums.lavag.org/LVOOP-ImageMagick-Interface-file90.html' target="_blank">nice wrappers for its command line syntax.

QUOTE (Antoine Châlons @ Mar 11 2009, 03:00 PM) Potentially it could be used on server side, but I'm not sure whether it would work compiled (uses scripting).

I found a way to significantly speed up brute force method. There are private methods in application class for dealing with password cache. Password may be verified using Get Lock State method of VI (it returns Pwd in Cache boolean). For the test case I created simple VI and locked it with "asd" password (to guarantee it will be found fast enough). I assumed (for test case only) that password consists of 3 non capital letters. For naive brute force method (providing password to Open VI Ref) password was found in ~50 sec (~600 checks). When using cache the same password was found in 5 sec. Of course 120 checks per second is not enough to seriously think about using this method to break VIs passwords. I didn't check yet what is more time consuming: adding to cache or getting lock state.

QUOTE (neBulus @ Feb 16 2009, 04:14 PM) But is this delay also used when applying passwords from cache?

Can't this "feature" be used to overcome brut force protection for VIs? If someone will find a way to fill the cache with a number of passwords, it can be used to try multiple passwords almost at once without any artificial pause.

QUOTE (Yair @ Feb 15 2009, 05:29 PM) Of course it will be as you said: Simple interface generating single SWF file easy to publish anywhere (+ maybe some code snippet to copy-paste making embedding even easier). Now it is just a functional prototype. What concerns merging with CCT (thanks for the proposition)- for me the only argument against is the license. Mine has to be GPL as I use GPLed SWFtools utility. I digged in this topic and I'm pretty sure that even calling external exe file with "system exec" (that's the way I'm doing this) obliges me to use GPL. Considering migration to something else, I investigated several other tools/libraries with less restrictive licenses butnone of them was as convienient as SWFtools. So as for now it has to be standalone tool and that's a pitty. I'm thinking about such a feature: vipreview (BTW is that name ok?) analyses structure of vi it was called for and its subVIs and their subVIs up to given level of nesting and then lets user choose VIs to be included in SWF file. Flash viewer lets to browse such a file in manner similar to LabVIEW IDE - clicking on subVI shows its code, list on the side (or expandable) lets to choose individual VI. How do you think - would it be helpful or only an overhead making UI more complex? What other features would you suggest?

After a year of doing something from time to time, investigating various flash generation libraries and turning whole the code up side down, we have another prerelease of VIpreVIEW (interactive preview of VI in flash). Visually almost anything was not changed and actually even code looks similar as in previous version (best ideas come at beginning), but: it is much faster (speed is already reasonable) flat sequence works (however it is implemented pretty ugly) fixed issue with showing labels from not visible frames fixed issue with additional 1 px border its is much faster (repeating this because I'm so proud of it) and what even better - it still may be faster (and I know more or less how to do it) Below some instructions copied from the first post: The main file is VIpreVIEW.vi. You have to open it, fill all paths, sizes, etc. and run (not very professional, isn't it?). After some work (depending on VI complexity) it will create a lot of files at target path. Most of them are temporary files, but I do not delete them yet for debug purposes. Open {name}.html file in a browser and watch the result. I included SWFtools binary in this package (it's GPL). Comments as always are welcome

I'm using 3D Scene Graph control to let the user select sth on 3D model. This control has method "Pick Model" which gets xy coordinates within control and outputs references of objects on proper line of sight. I'm getting xy coordinates with "Mouse Down" event for that control and it works. But how to determine which point exactly user clicked? In terms of 3D coords, uv, face number or sth like this? Have I to manually calculate intersection of object and line of sight taking into account current projection and transformation? Generally quite complex (requires space sorting algorithm) and potentially slow... Another point. I would prefer to use rather 3D window than a control, because of speed. SceneWindow class has similar method - "Pick". But how to determine xy coordinates user clicked at? Have I to use API for that? LV 8.2.1

QUOTE (Aristos Queue @ Jan 23 2009, 05:55 PM) I would like only to mention that VIpreVIEW project is not dead but suffers from sickness called "notimeness". I have some children who demand my attention louder than it...

QUOTE (Yair @ Jan 8 2009, 09:20 PM) Depends what kind of data is passed with q/n. But in general in fact it would be better to use FGV to store q/n references flattened to variant (to avoid many kinds of them).

QUOTE (jlokanis @ Jan 7 2009, 08:41 PM) Use only one type of queues/notifieres - variant. You get additional opportunities with variant attributes.

There is another solution - you can store all refs within functional global.

I've just figured out that in case I described when you click on index rectangle, value of array element also changes. So either hide an index rectangle or check whether user clicked there

QUOTE (Norm Kirchner @ Dec 22 2008, 06:32 AM) There is much simpler approach. Array control has "Array element" propperty, which has Value property of variant type. Reading this property inside event structure for whole array event always gives you value of clicked array element (flattened to variant). If you want to get an index you can get reference of "Array Element" and search for it in array of references created before for your control. The last is not as trivial (AFAIK), at least dynamically.

Also when you put image on front panel as a decoration transparency smoothness is preserved. I was playing around with scripting trying to dynamically change such decoration, but without success.

There are "Get Property" and "Sete Property" private methods in Generic class. They looks like they set/get properties via property index and using variant type. But you have to know these indices. First several thousands (from 0) does not work for simple digital control Maybe any of our "rusty nailers" knows sth more?

As it is still not clear where to continue the discussion, I cross-post my two cents here: For some time I use AE based on variant with named attributes. Just to limit constantly number of get/set methods and shift registers in main VI. With such approach I have only one variant variable in main VI and one method for set and one for get. I provide name of the variable to these methods with string constant and check whether attribute exist inside get method. The disadvatage is that I have to unflatten variant to proper type after getting and this takes a place. What I'm thinkig of to solve that problem is to create XNode which would serve as universal get method adapting type of its output basing on input string and type definitions stored i.e. as a named constant in main VI. Unfortunatelly I have to find some time to deep into XNodes... And for my type of AE wrapping all other methods in polymorphic VI is definitely a good idea... QUOTE ...but strictly for AE, not so generally. Why? Because usually there are only few methods other than get and set (at least in my AEs) and they are all designed to be used, so loading all of them to memory at once is not a con (BTW bad to hear that Aristos, that means a lot of unnecessary functions are being loaded into memory in my programs - a lot of analitycal functions in LV are polymorphic. I have to think about using their instances directly). 90% of my VIs use 4-2-2-4 pattern so for me this limitation is not a con. So with such approach I'll have only 3 items on AE palette (and I use only one AE per application, see above) - I can keep such a small pallette permanently open, even on my laptop. The only con I can think of is instance selector - it takes too much place.

QUOTE (shoneill) It is password-protected in my version QUOTE (shoneill) You can also cast a U32 to a cluster containing 4 U8 instead of using the sub-VI. It's actually faster if I remember correctly. Splin Number based method is fastest I found. I'm going to enclose it in subroutine VI and use it further and I suggest to do so to everyone who perform extensive pixel manipulation.

I just realized that LV "Color to RGB" function from graphics palette in unexpectably slow. I recognized with simple test that it is about 700 times slower than using Split Number function three times to get color components. There is no such issue with "RGB to Color" function. VI with test case attached LV 8.2.1

Here is a simple tool I wrote some time ago, where I used copy-paste mechanism to drop something on BD.

QUOTE (gmart @ Nov 17 2008, 10:59 PM) Brilliant! It is enough to chenge the printer in Page Setup to something local and Properties dialog brings up immidiately! Why I didn't know about it month ago when I had to update documentation of 100+ VIs...

QUOTE (Aristos Queue @ Nov 17 2008, 10:12 PM) a) as in profile - 8.2.1 b) first time after bringing VI to front is often longer, but it is not a strict rule. Restarting LV does not change it in statistically meaningful way. I only see it correlates with project size - for very small projects launching dialog is faster - however still not as fast as I would expect from relatively simple dialog (at least visually )