Leaderboard

Name: Open Office RGT addon Submitter: Francois Normandin Submitted: 18 Jan 2010 Category: LabVIEW IDE LabVIEW Version: 2009License Type: BSD (Most common) Public Git repo (source code): https://bitbucket.org/normandinf/openofficergt ==================================== Open Office RGT addon v0.2.0 beta Copyright © 2010-2016, François Normandin. All rights reserved. Author:François Normandin Contact Info: Contact via PM on www.lavag.org LabVIEW Versions: Created and tested with LabVIEW 2009 Dependencies: Report Generation toolkit (part of it is included in the base package: Word & Excel require license) Description: This package contains an installer and class to use the AODL (An OpenDocument library) with the Report Generation toolkit from National Instruments. Includes: - ooWriter class - AODL classes (and DLLs) - PreInstall and PreUninstall VIs to backup the only modified NI VI: New Report.vi (in Utility\NIReport.llb) Instructions: After installing package with VIPM, use the NI Report Generation palette as usual. Known Issues: 1- ooWriter: Styles integration is incomplete. Needs to have a real "style" class created that will comply with current standard in RGT. Adding an image is not working correctly: it is embedded in a paragraph instead of being standalone. 2- ooCalc: no integration yet, but rather similar to ooWriter in principle. (All the roadblocks will be cleared by ooWriter) 3- This code has been done with LV2009. I see no problem for using with LV 8.2 and up, it's just a matter of saving for previous version and distribute. This will be done at a later date. Acknowledgements: National Instruments. (NI Report Generation Toolkit) ** LVOOP rocks ** AODL by Sun Microsystems, Inc. Copyright 2007 History: v0.2.0: released on bitbucket (Git) for community v0.1.0: Initial release of the code. (LV2009) License: LabVIEW libraries of OpenOffice for RGT addon are licensed under BSD. AODL us distributed under the LGPL license. (see license files for more detail) Support: If you have any problems with this code or want to suggest features: please go to www.lavag.org and Navigate to the discussion page. Distribution: This code was downloaded from the LAVA Code Repository found at www.lavag.org ============================ Click here to download this file

What are the circle things supposed to be on the cover of this book? (there is an addition and a subtraction primitive coming out of one of them)

Gravity Waves? Actually they're shockwaves of insight emanating from each reader as they progress through the book. These waves propagate outward spherically (the book cover is merely a 2d projection!) and intersect with the shockwaves produced by other readers, in places like LAVA. What's interesting is that these waves have special properties. First, the energy of any point on the wavefront is not a function of its distance from the origin. That's to say that the farther the wave travels and the more people it touches, the more total energy it carries. Secondly, when multiple waves intersect at a given point, they always interfere constructively.

I think you mean "science SHOULD'NT work that way". If you look throughout history, scientists are not exactly above being petty, vindictive and short-sighted. When you couple that with the constant fight for limited resources (you can't do research for free), you get even more justification to get the Money Man to give the money to you and not that pesky scientist with the opposing theory. FWIW, I am skeptical in this issue. I do think that GW is probably represented incorrectly. The difference is that in my case it's just a feeling, nothing more, since I don't have anything concrete to base that feeling on. And I certainly agree that sometime people take one side and believe it to be gospel even without basis. That does not mean the other side is necessarily correct. Debate, in itself, is not helpful, as this is a scientific issue - either the scientists can tell us what's going on or they can't. After that, it's a political issue of deciding what to do, and that's where the debate is relevant.

I've received a few PMs concerning this. Thanks all for waiting. The last few weeks, I've had less time than I would have wanted to continue this work and I am posting my preliminary work as is. There are a lot of holes in there, especially since I have not yet begun coding for the Spreadsheet Documents (Calc), only for Writer. Furthermore, the utility VIs like "Set Font" and "Save to File" should be much more "intelligent". As of today, use a correct OpenOffice filename with a ODT extension to save your work. Remember that this is preliminary, but it makes use of the NI Report Generation Toolkit that handily comes coded in LVOOP. The "New Report.vi" VI is being replaced by one that can select ooWriter and ooCalc among others. The AODL libraries (DLLs) are installed in the vi.lib\Utility\NIReport.llb\ooWriter\AODL folder. I have not yet touched all the power of playing with Cell contents, which will be necessary for upgrading to ooCalc eventually. From now on, please use the discussion thread that was created with the submission in Code Rep for any comments on code or suggestions. BTW, this is coded in LV 2009... but I don't see a problem in the future to downgrade the code to 8.2. I just don't have time for the moment to test it. (Please bear with me.) Enjoy!

Both sides cannot be true. Either the earth is warming or it is not. Either man is causing GW or we are not. That is where the scientific method and debate comes in. The pro GW/"CC" advocates attempted to stop the debate, and called a (IMO premature) "victory" when they stated: "the science is settled." Those of us who are skeptical beg to differ. To claim "victory" when the science is far from settled while the welfare of our planet Earth is at stake is arrogant and dangerous. You cannot, as a scientist, claim "I WON!", pick up your marbles and go home and start influencing policy that costs trillions of dollars and will affect billions of people. Adults don't act that way. Science doesn't work that way. We need to be smarter than this.

On a related note, when making architecture framework code that includes User/Dynamic events..... A little known fact is that you can register multiple Event Registration Refnums to an individual Event structure. So you ask, "What does this mean to us and why do we care?" First this is what it looks like What is happening here does not show the full power or reason I bring it up. But rather it shows the base Mechanics. This little piece of code registers a different Event Registration Reference for a user event that just got fired.... With a little creativity, you could to a TON of things with that idea (but it's still not why I bring this up. The reason that this technique is so important to event based architectures is that dynamic events do not all need to be lumped together within 1 DynEvent Registration Reference. You can Separate them better based upon functionality. In particular, if you make an architecture that you want someone else to take advantage of, you can isolate your architecture/framework events and registrations and other functionalities within your own framework code and not need to have them modify or tweak their own RegEventRef just because you may have changed or added something to the framework. A great example of this is the ever elusive "Initialization Event" So many people have skinned this cat, it's starting to chafe some. This is a typical way to have an event case fired at startup. But it makes this portion of code a bit bloated and it's just not as elegant as it could be. Now the mechanics of this flow still need to happen. But watch what we can do if we take advantage of the previous technique. The top VI now is a framework level VI that I can drop in any VI that I want to run an INIT case on, without disturbing the definition of the Event Registration Refnum of the rest of the program. The bottom VI just did the same thing by taking that registration process and made it an individual VI that prevents the end user from needing to wire up a bunch of stuff they should not need to worry about. Hopefully this technique (which you can do in 8.6) will aid your architecture

Quite easy, and in fact you don't even need the OpenG VIs, since you can just build an array of reference and then iterate over them and use the variant Value property flattened to a string. Then you just need a VI for saving and a VI for loading and you're set. Whenever you want to add a control, you just create a reference for it and add that to the array.