Doon

QUOTE(Jeff Plotzke @ Mar 14 2007, 05:23 PM) Touché I would like to qualify my solution. It does result in purpose-built (i.e., very specific) interfaces. Further, the interfaces I have written do not actively consider validation or well-formedness (By design, the generated XML is both valid and well-formed [as long as no one modifies the XML externally ]). Straight text-parsing is definitely worth considering for simple (i.e., shallow) XML files. The XML database I have implemented is no more than three levels deep, and is very wide at the top level. For anything more complex, I agree with Mr. Plotzke that a generic XML parser is a better solution. I cannot comment on the utility of the native LabVIEW Internet Toolkit as I have not used it, but I hear it's pretty cool. Cheers! --H

This may be an unpopular alternative , but XML is marked-up plain text. One can read/write XML files without much hassle at all. I have developed an XML database that records serial numbers and tracks changes to modules. It took me about a day to write the core vi's needed to interface with the XML database (add, remove, modify, and resolve). I decided to go this route because of cost and speed. A purpose-built text-parser will (usually ) always perform better than a general purpose XML parser. I <heart> XML -H

This is just an idea , but have you tried using the "Key Down" event inside your XControl? I suspect it would be possible to redirect characters "typed" on the XControl into the XControl's string. cheers! --H

I have built a simple "LVBA" application that opens excel, creates data, builds a chart and adds a second Axis. It's a bit hurried, but I did take the time to annotate my code. :thumbup: FYI, Atul, all VBA code written in LabVIEW ends up looking like that. I would normally break this sort of thing into a bunch of sub-vi's. One thing I've done in the past was to build a template with the charts already properly formatted, etc., and simply add the data to spreadsheet. That worked out quite well, but took a great deal of time to tweak. I would suggest this sort of thing if you are using your code to generate a test data report. I hope that helps --H

Hiya, Firstly, I would like to warn you that interfacing with MS Office applications is not difficult, but it definitely ain't no cup of tea, either. :thumbdown: Also, you may run into trouble when you upgrade to a new version of MS Office. QUOTE(ats @ Feb 21 2007, 11:12 AM) Essentially, interfacing with MS Office through ActiveX allows you to run VBA code externally. What I found as a quick way to "see how things work" with VBA is to use the macro-record feature in Excel, and look at the generated code. That will give you an idea of how to programatically build a 2-axis graph. The LV code will turn out to be a bunch of property nodes and methods which graphically mimic the VBA code (that's the way I think of it). LV 8 is great in that it allows you to look-up help for VBA properties and methods directly from the block diagram. Alternatively, you can build the macro in Excel and simply "call" it from LV. I think this was covered in the available examples. I hope that helps, --H

Adding my two cents: It would also be good to note that some of the add-ons available for LabVIEW are listed as "Windows, Not in Base Package" (e.g., MathScript). You may want to check for add-on availablity as part of your decision. -H

Thank you for your responses That's a wonderful idea; I shall be implementing this as a standard for my one-sided xcontrols. Strangely enough, this causes LabVIEW to become unstable (Windows throws an exception and kills the LabVIEW). Perhaps it's a problem with 8.0.1. I was able to reproduce the effect in different XControl initialization senarios (dropping from palette, copying, etc.). I am interested to see if anyone else gets the Windows panic. FYI, the xcontrol is a simple numerical indicator that changes color depending on value. In its current configuration, Windows throws an exception when I copy the xcontrol. have a nice day, --H Download File:post-3343-1170373251.zip

Hi everybody! I have an XControl that only has indicator functionality. However, when I place it on the front panel of a VI, it defaults to control. So far, the only thing I have tried is to set the default state (RMB>>Data Operations>>Make Current Values Default) of the Container State cluster in the "Init" VI. This did not work. Any thoughts, suggestings, solutions, or flames are welcome. :worship: -H

tcplomp, Using the "Link to Directory" method, I had no problems getting xControls to show up. -H

Oh yeah, I didn't catch that. Thanks for pointing that out, tcplomp --- orko, As near as I can tell, one cannot give array elements different properties (e.g, color, font style). One possible (almost-)solution is to build an array of numeric indicators in front of an array of color indicators and set the color values based on your conditionals. I have built a small vi (with a big name) that demonstrates my suggestion. I hope that helps, --H Download File:post-3343-1169221347.vi

Hiya orko, If control Scaling is not an issue, you can unset the VI Properties>>Window Size>>"Scale . . . as window resizes" checkbox. Then after you plop the XControl onto your Front Panel, you can resize the XControl's container down to the right size. Hope that helps, --H

This sounds like it could be one of two things: a regex problem, or a file sizing issue (file re-sizing, to be specific). LV regular expressions are the bane of my existence (every once-in-a-while). If I could see your code, I might be able to help. -H

What a nifty gauge, Mr. Punk. :thumbup: I have already found a use for it in my work! have a nice day, -H

Hiya, I just ran into your list of posts, but I figured that I shall add my two cents. I found that one could mimic an "absolute value" type gauge using (abusing) the "Text Labels" feature. Text labels seem to have been intended for integer gauges, but work (-ish) for floating point. Each value on the scale is actually a text value at the appropriate scale value (e.g., ".8" at "-0.8"). Please look at the attached code for explain. I agree with Mr. Habets about adding a second needle. You can customize (Advanced>>customize) the needle to look more like a marker. In the attached, I used a separate gauge to save from changing datatype to cluster. I painted the border decorations transparent so that it would appear as a single indicator. I hope that helps. -H Download File:post-3343-1167763317.vi

Are you looking for an Oscilloscope-type indicator? Then I would suggest using the Waveform Chart indicator. Under the "Appearance" tab of the indicator properties, you will find a combo-box labelled "update mode". With this, you can set the indicator to display like an o-scope. I hope that helps, 8D

i think this is a simple indicator formatting issue,

I only thought of this after a month of programming in Java (i.e., I'm out of the LV mindset): To my knowledge, LabVIEW case structures -- when wired to an Error data-type -- only allow two conditions: "Error" and "No Error". I need a way to handle "Error, code X" and "Error, code Y" and a default (unhandled) Error. Right now my only solution is to nest two case structures, one to catch the error, and one to catch the code. It bothers me that I have to send so many tunnels through nested cases. :headbang: Thanks, in advance, --H

Hiya rsd3k, Firstly, you can create a local vairable in LabVIEW. Simply create an indicator at the output of your eXOR gate. Then right-click the indicator terminal and select Create>Local Variable. However, I have been taught that it is better to use data-path precidence than using sequence structures. As I understand, every one of those little squares between frames results in a new data instance (i.e., a new memory alocation). I would do away with the frames, altogether, and use the error path to establish order. That is, connect the error out of the first sub-vi to the error in of the next, and so on. LabVIEW only executes a sub-vi when all of its input lines have data. hope that helps