Leaderboard

Just right click and select "generate code". Nothing clever. Even I can do it

I normally don't post on LAVA, but lately I have been experimenting with the WebSocket protocol, ecmascript, and the SVG DOM for creating animated browser displays with data streamed from LabVIEW. The technique is surprisingly simple. All you have to do is create a script to change the attributes of the SVG elements using the Document Object Model. The WebSocket protocol has a built in message event handler that allows you to create your own script function which executes when messages are received. The browser connects to the socket server and sends a handshake when you create the WebSocket object in script. All you need do is put a TCP/IP listerner in your diagram and return this handshake as described in the wikipedia article on WebSockets. Once the connection is made, you can stream bidirectional data between your LabVIEW application and any bleeding edge browser (Firefox 4, Chrome 9, Safari, IE9?). You can use the DOM to set the transform attributes of SVG elements using the streamed info (rotate, scale, set heigh, width, line points, etc.). Now that we can all design our own GUI objects using Inkscape (free), I suggest a concerted effor to develop a standard SVG format, streaming protocol (based on WebSockets) and open-source script library. The very best thing about this is that it is all FREE, and runs on any platform that has an HTML5/SVG/WebSockets supporting browser (I'm keeping my fingers crossed for the next firmware revision of the Nintendo DSi), and requires NO PLUGINS. So all you folks with iOS and Android who feel left out by the WebUI Builder, or those of us who are infurated by it's $1500/yr price tag (after spending $ on LabVIEW RT/FPGA), Cheer Up! Here are some screenshots of my efforts. The files are opened in the OS, but will also work when served by the old-fashioned "non-webservices" LV web server (you gotta add an SVG mime type to the mime-types file). You can also use RGraph Library and the HTML <canvas> tag if you want to implement a non-SVG browser solution. The library is free for non-commercial use. I suggest a community effort the create the standard SVG formats for UI elements, and a free, open-source ecmascript library for handling the messaging and DOM animation tasks. If there is interest, I will upload my script as a starting point, but I must warn that there is much improvement needed. sm

Yer, MP does not support all of the same special characters as regex, so I too jump between them for speed or functionality to meet requirements. ShaunR - how do you know so much about the LabVIEW internals on these functions (which is great btw)?

The regular expression primitive is actually an xnode (the tell-tale busy cursor whilst it generates the code). Once the code is generated by the xnode your string is passed to the regex function in the labview.exe (MatchRegExpEfficient). But. When it' returns, it is parsed in Gcode using several split string functions to split out to the terminals. So not only do you have a regex engine overhead (which may or may not be the same as match pattern - i don't think it is). But you also have 4 or 5 (more if you grow the terminals) additional split strings.. So at best, the regex function would be 4 or 5 times slower, even without the call to labview. But match pattern (as blazingly fast as it is) becomes unwieldy and difficult to use on selective string matching (where something may or may not be present - like area codes in a telephone number). That's when you need the regex. NB: Your image shows 75k for the match pattern and 210k for Tons.

Actually a correction to my earlier post. The VI library mentioned does not allow to see all the registered services but instead you can enter in your prefered WebBrowser: http://localhost:3580/dumpinfo?

Hi LAVAs, I already picked the curiosity of some of you guys with this Open Office Report Generation toolkit. So here is a snapshot of what's gonna be made accessible shortly through the Code Rep. But most importantly, I'd like to know what would be useful for the community. I'm having a design decision to make at the moment and I want to get people's opinions. The toolkit will be based on AODL, a .NET API for Open Document Format. It's still in beta (v1.3) and includes only Text Documents and Spreadsheets, but it's a complete interface. It's a complicated API, but after spendig a few days poking around it, it's a quite simple mechanics. I'm building this toolkit with LVOOP. For the moment, the "Basic" palette is taking form: * Init Document * List Styles * Add Text * Add Table * Add Table of Content * Add Image * Save * Load * Dispose() To be used somehow like this: That's fairly straightforward. Where it gets a little more complicated is that I'd like to propose a true API to extract one part of a document and modify it. For that, each token that is constructed (Content of document) needs to be done by first creating the empty construct with the document reference as input. I haven't found a way yet to create content without first assigning a document reference. (i.e. I would like to find a way to create it with an empty reference and change that reference later on when I decide which document I want to add this content to.) This constraint quickly adds a bad feel to the whole exercise... What a spaghetti! So I might solve this problem by creating an active directory a FGV of current documents references (provided there are many) and each new content class (i.e. Create Empty Table) would be provided a Document Name to search the reference in the directory. This allow addition or modification of content in a State Machine. I can see why some people would not like this idea because it clearly breaks dataflow... but since the .NET API is by-reference, perhaps it's an acceptable compromise. The final toolkit would include some Advanced palette to edit, insert before/after, include content inside other structures recursively, and the like. My initial tests with LVOOP indicate this could be quite versatile and expandable as the AODL (An Open Document Library) is extended. Any thoughts on this? I'd like to hear your design advices as well as any requested features for the first draft. PS: BTW, this AODL API is great. You can create reports without OpenOffice being istalled on the machine! I still haven't looked at the "Save as DOC file" yet, but it shows promises.