Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/14/2009 in all areas

  1. 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.
    3 points
  2. Imitation is the sincerest form of flattery - Charles Caleb Colton (1780-1832) Firstly I would like to say that I did not originate this idea, I first saw it posted on the JKI Blog by Justin Goeres. However, no code was posted, so I took what was there (GUI screenshot, BD screenshot, explanations etc..), said thank you, and came up with this. Of course I read Joel on Software and other books on (java) build scripts and seen other posts discussing LabVIEW build scripts etc.. but I wanted to make the above point up front as it is going to be very similar, but it was a great blog post about a great idea with a great example and I decided to implement it, use it and share it - with LAVA. So I hope its all ok. Thanks for listening. Below are some notes on the code: Since I was going to make this a template (.vit) a put a bit of extra GUI code in it. I wanted a clear visual sign when I came back to my desk that this thing had worked. Or something had happened to make it fail. I also wanted to know the time it takes to build the project. With classes and libraries the build time can blow out from seconds to minutes (over 10) for some projects. Although 2009 seems much faster than 8.6. So I added another thread for a simple timer. This script has support for 9.x builds. I found straight away I would get errors if my src code and dist folder where deeply nested in the folder hierarchy on the OS. 9.x solved the ugly build problem of files outside the exe, but it left me with a sour taste as my build frequently stopped due to error. This script solves the problem by transparently build in other folder (e.g. D:\dist) then coping these back to the Project. The only catch is (because reading the file XML tags in the project looks daunting) the 9.x Root path must match the start of the path in the build spec. Because I use the same location D:\dist I add a Project folder for each Project e.g. D:\dist\Project. the all the builds get located under here e.g. D:\dist\Project\application or D:\dist\Project\installer etc.. The architecture of the template is implemented using the JKI State Machine. Which is great for building GUI's quickly. If you want to copy then edit this build for other projects (I had it as a .vit) then you will need to update the Project Details. The folder structure is hard-coded as this is a standard I use. All folders are relative to the project though. And there are some example files copied to the zip (for the creation of a CD). I use NI's UTF a lot and this can run tests in the Project automatically. It can even decide to kill the build if tests fail. It is disabled in the distribution in case it is not installed. Other The application build Version can be auto-incremented and the installer Version is matched to it. Support code used can be found in ..\lib. The subVIs are from libraries I use. You may find some reuse options in there. I have been playing around with an AUTO feature that essentially defines constants for the GUI and therefore this script could be called by something else (e.g. as subVI) for an automated build (e.g. nightly). I am looking doing the following in the future Converting the .zip to an ISO so it's ready to burn; Archiving zip if its a release to server, SCC actions, This code is a start and I would love to see what other people are doing and add to this over time. Hope you enjoy it.
    2 points
  3. Name: Build Script Submitter: jgcode Submitted: 13 Nov 2009 File Updated: 03 Jan 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) Build Script v1.1.0 Copyright © 2009, Jonathon Green; JGCODE All rights reserved. Author: Jonathon Green LAVA Name: jgcode Contact Info: Contact via PM on lavag.org LabVIEW Versions: LabVIEW 8.6 LabVIEW 2009 Dependencies: jki_lib_state_machine >= 2.0.0 jki_rsc_toolkits_palette >= 1.1 oglib_array >= 2.0 oglib_appcontrol >= 2.0 ogrsc_dynamicpalette >= 0.2 oglib_error >= 2.0 oglib_file >= 2.5 Unit Test Framework (optional) Description: Contains a build script for a LabVIEW Project. Use a build script in your development to automate the task of, and avoid errors when, creating deliverables. A sample project is included that creates an application, installer then archive (.zip) for a project. This build script supports the new 9.x build format by building the specs in a high level temp folder (e.g. C:\dist) to minimise errors occurring from the OS exceeding maximum number of characters in path. NI's Unit Test Framework (UTF) is supported or code can be added for other Unit Test APIs (see Unit Test Framwork.png for demo code). Installation and instructions: The dist folder contains build.vit and a library (.llb) of support code. See Examples section on how to use code. Examples: 1. Open example\Project.lvprj 2. Open and run build.vi, VI should complete execution with no errors 3. Once build script has completed explore example\dist to view all builds (application, installer, zip) 4. Unzip zip folder and install application 5. Run the application 6. "Build Works!" dialog should appear to indicate sucessful build 7. Reuse script a. Use build.vit as starting template for project b. Edit the project details on the block diagram to match to new project Known Issues: No Known Issues Acknowledgements: Justin Goeres (JKI) Joel Spolsky JKI (JKI State Machine) OpenG ICON Technologies Version History (Changelist): 1.1.0 2009 11 15 [Fix] Code saved to LabVIEW 8.6 on request from LAVA member. Unit Test Framework VIs were removed due to build issue. [Fix] SubVIs added to a .lvlib within a .llb. 1.0.0 2009 11 14 [Feature] Initial release of the code (LabVIEW 2009). License: BSD Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the Build Script support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file
    1 point
  4. I have updated the Hook. Changelist 1.1.0-1 2009 11 13 - New (Free Label): Added a free label and space for a comment in the case structure. Normally I don't need one for basic get/set but it is handy to have one their for the future. Custom User Scripting For New Simple Accessor VI.vi [LabVIEW2009]
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.