Jump to content

Bob Schor

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Bob Schor

  1. I've been using VIPM for years to access the LabVIEW Tools Network. Recently, one of my machines was set up with a User Account (where I do most of my work) and a separate Admin account. A while ago, I tried to install EasyXML and got a strange error (among other things, I was told the package was not compatible with my OS nor any version of LabVIEW installed on my computer). Turns out the "fix" was to run VIPM from my Admin account. But do I learn? No, months later, I try to install another package. Similar error. While browsing this Forum, I run across my previous note and see "Run VIPM as Administrator", which (are you surprised?) fixes this "new" error. You'd think I would have learned my lesson, but I can at least pass on this warning. Bob Schor
  2. Running as Administrator did it! I was about to do a Follow-up Post saying I'd just "built" a second PC with LabVIEW (on a system where my normal account is NOT an Admin account, just like the PC where I had the problem), and over here (PC-2), EasyXML installed without problems. So back to PC-1 (where the problem occurred), did Steps 1-3, no go, but Step 4 worked. Who knows, some permission flag got "stuck", I guess ... Many thanks for the quick response. Bob Schor
  3. I've just (re-)installed LabVIEW 2016 (32-bit), 2018 SP1 (32-bit), and 2019 (32-bit) on a Windows 10 PC. I successfully installed the OpenG Toolkit in LabVIEW 2018 (so VIPM 2019 is clearly working). When I try to install EasyXML, I get an Error message: Main Package Name: EasyXML Toolkit for LabVIEW v3.0.0.170 Package Name with Error: EasyXML Toolkit for LabVIEW v3.0.0.170 Error Message: VIPM could not install the package jki_lib_easyxml- . Error Code: 8 Error Source: Open/Create/Replace File in C67C17A61D892A779727551BEF09A84E->43105161E3ECC5D5EE650DF274C1CB11->0ED5338B9A29C49A512F6049C2CCAE99->1DBEABF39FB76470575E756F0E9DB3AC->87355405EFC0DDB6ACE0A96175E31D86->OGPM Class.lvlib:89AC7BADF759B8183E200C1F7AFA7855->OGPM Class.lvlib:3617A98EB64CF6012064A2A881466B07->579BE417495B7ADCD1FF111EE165D832->VIPM Main Window.vi<APPEND> C:\ProgramData\JKI\VIPM\cache\jki_lib_easyxml- =============== Please advise how to proceed. Bob Schor
  4. It is about four years later, I'm re-installing EasyXML, and this Example is still broken. The newly-installed Package still has the 4-year-old "wrong" Address, not the "corrected" one listed above. Why not put the "right" address in the Package? When I manually put the corrected address in and tried to run the example, I got "Error 1181 occurred at DataSocket Read in Read RSS Feed.vi. Possible reason: Protocol not recognized by LabVIEW. Can you please do the following: (1) Figure out how to make this example work! (2) Update your Package Repository to include the repaired, working Exmple. Bob Schor
  5. SOLVED. After three months of silence, I followed up with phone calls and e-mails to JKI, and got a response. The suggestion was to download VIPM 14.2.1976 (which I had done), and install it with "Run as Administrator". On my Windows 10 (Enterprise) PC, I am in the Administrator Group (though I don't use the "defined Admin" account). I tried it both ways, after a fresh reboot. Installing without elevating my privilege gave the same Error Message. Installing with Run As Administrator did, in fact, work. Some Questions. Did JKI not know of this "requirement" with Windows 10? Had they not tested it? If they did know, why were there no "fixes" or "warnings" built into the latest Software? Why is there no information either here in the JKI Forums or on the JKI VIPM main pages? Why did it take >3 months and my "yelling" to get a response? Yes, now I do feel better. I still think that JKI are a great group of people, and will continue to support them and their products. And (best of all) I now have the Hidden Gems In VILib on my Windows 10 LabVIEW 2015 system! Bob Schor
  6. Well, it's a month later, and I'm still having problems with VIPM and Windows 10. I should mention that I am using VIPM 14.0.2, and a check says "Your software is up to date". I have several machines running Windows 7 (x64) and one running Windows 10 (x64). All my machines have LabVIEW 2014 (32-bit) and LabVIEW 2015 (32-bit). My VIPM problems are exclusively with the Windows 10 machine. I have managed to install the OpenG Toolkit and one or two other Toolkits (I think I have the Biomedical Toolkit under LabVIEW 2014). However, attempts to install the "Hidden Gems in VI.lib" on either LabVIEW 2014 or LabVIEW 2015 met with failures, and the following Error Message: Main Package Name: Hidden Gems in vi.lib v1.0.0.8 Package Name with Error: Hidden Gems in vi.lib v1.0.0.8 Error Message: VIPM could not install the package national_instruments_lib_hidden_gems_in_vi_lib- . Error Code: 8 Error Source: Open/Create/Replace File in 21C4387AAE161FADBB1B2CA3A9EA1E5B->32E4E917A65244952F75E76C7A772B37->9DD90B2ABCC05E64EEB423775FEE5AA4->0514BDAA838359D0AD33ACAFA20FBC99->F94B9712B58831359A5E0BC2B53B4AFD->OGPM Class.lvlib:AE5C17D32A658827574CE56AD11AA4E5->OGPM Class.lvlib:C43A876EE83195DB5AD53919EE545D96->04B61BB9511860B66C121A638B9449D9->VIPM Main Window.vi<APPEND> C:\ProgramData\JKI\VIPM\cache\national_instruments_lib_hidden_gems_in_vi_lib- =============== I would appreciate some clue as to how to proceed, as well as some understanding of the nature of the failure. Bob Schor
  7. Well, I don't get it. There's something funny in the Windows 10 "water" (I've been using it only 3 days, still learning its idiosynchrasies). So after seeing the (very) early returns from Iowa, I tried again with VIPM, LabVIEW 2014, both 2014 and 2015 ports set to 3363. And (as it has in the past 4-5 years for me), VIPM installed packages without a hitch! Not at all sure what the difference was a half hour ago (except I didn't know about the caucuses), but I'm going to leave Well Enough Alone. I've now got my most important packages installed on the two (so far) versions of LabVIEW on my new Windows 10 PC. Time to get some work done ... BS
  8. Sigh. When will I learn? VIPM/LabVIEW 2015 (the first I tested when I (re-)installed Build 1976) worked fine, loading several packages. However, a complete failure with LabVIEW 2014. Ever since I started using VIPM, I've had multiple LabVIEW versions (typically at least 4 versions), and all of them were configured identically, all using TCP/IP port 3363 (if VIPM set up up as different, I set them all back to the same port, depending on the previous observation that if I was on a VIPM 2015 page, it would (only) try to connect to 2015. Now, with VIPM 2014.0.2, build 1976, with Windows 10, LabVIEW 2014 (SP1), I've been able to install packages in 2015, but none yet in 2014. Will keep trying, but it's never been so difficult ... BS
  9. OK, problem solved! Downloaded 14.0.2 Build 1976. Two installs with LabVIEW 2015, Windows 10 were flawless, what I've come to expect. I guess when I installed the Latest OS, the Latest LabVIEW, I somehow got the "almost-latest" VIPM ... Bob Schor
  10. Followup on reboot -- same failure with LV 2015, NI GXML. So I tried OpenG Toolkit. Barely started when it stopped, red letters at the top of the Package Information page says "This package is not compatible with your operating system or any LabVIEW version installed on your computer. As I noted before, last week I successfully installed LabVIEW 2014 and 2015 on a Windows 7 (x64) PC (not new) and had no trouble loading packages with VIPM. Now I'm doing the same on a new PC built with Windows 10 (x64), same versions of LabVIEW (2014 and 2015), which seem to work fine. Is it really true that VIPM is not compatible with "my operating system", i.e. Windows 10? I find that hard to believe. After posting this note, I'll go to the Web, download it again (I probably installed from the LabVIEW disks -- the version, I think, is 14.0.1 Build 1967. Incidentally, when I clicked "submit" on the previous post, the "busy wheel" spun for perhaps 3 minutes or more ... Bob Schor (maybe it's the Iowa caucuses messing with the electrons running around inside my PC ...)
  11. Over the weekend, I installed Windows 10 (64-bit) on a new PC, and started installing software. Late yesterday, I installed LabVIEW 2014 and LabVIEW 2015, and to my surprise, did not have any installation problems (I did a similar install two weeks ago on a Windows 7 system with multiple "Service not running" bugs, since fixed). I just installed VIPM 14.0 and activated my Pro license. I successfully connected to both LabVIEW versions, downloaded packages, and then tried to install. I usually start with a single package, NI GXML, then do the OpenG Toolkit. I got bizarre errors when doing this. Nothing installed, on either 2014 or 2015. I'm going to try to paste the error message I got when trying to install GXML on LV 2015: [Oops -- can't figure out how to post a SnagIt snapshot, thought the Image menu button would work like the LabVIEW Forums and let me find the image on my disk, but it wants a URL ...] So here (I hope) is a Copy/Paste of the text ... Main Package Name: NI GXML v1.4.2.8 Package Name with Error: NI GXML v1.4.2.8 Error Message: VIPM could not install the package ni_lib_gxml- . Error Code: 8 Error Source: Open/Create/Replace File in 23163E1A41169BF347A8CCAAC0675BD9->737916C70F04A06F7315252588CFE2EA->EDC783C0EDD9EFF57211A26F185B4235->3CEEB42FDB9E41319885C763266FF802->C3E21B565FCD6F248FD8C7F70DCA4E74->OGPM Class.lvlib:F1B7AB8155DFB5A57C76E744EBF6D846->OGPM Class.lvlib:8DA808F6EDC3F497E0970966EA075B32->151384EDD6F89B08F780714EAD830768->VIPM Main Window.vi<APPEND> C:\ProgramData\JKI\VIPM\cache\ni_lib_gxml- =============== I'm going to try a few more times, with reboots in between. Never had VIPM flat out fail on me (I have had problems with I forgot to enable TCP/IP, but I haven't made that mistake in at least 5 years ...) Bob Schor
  12. I just tried the Read RSS Feed example for EasyXML 2.0, and failed the parse. I'm guessing that the rss cluster that "defines" the parse is very wrong. The feed is coming from http://forums.lavag.org/rss-8.html. The first few lines of the raw rss data are: <!DOCTYPE html> <html lang="en" xmlns:fb="http://www.facebook.com/2008/fbml"> <head> <meta charset="UTF-8" /> <title>LAVA</title> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <link rel="shortcut icon" href='https://lavag.org/favicon.ico'/> <link rel="image_src" href='https://lavag.org/public/style_images/master/meta_image.png'/> <script type='text/javascript'> //<![CDATA[ jsDebug = 0; /* Must come before JS includes */ DISABLE_AJAX = parseInt(0); /* Disables ajax requests where text is sent to the DB; helpful for charset issues */ inACP = false; var isRTL = false; var rtlIe = ''; var rtlFull = ''; //]]> </script> Please advise. Is there an alternate rss site that I might use to see this in action? Bob Schor
  13. OK, so a "simple install" (just click the downloaded installer) fails because "The product is already installed". Go to Control Panel, remove VIPM 2014, and try again. This time, it installs, and actually seems to run! Hooray. BS
  14. I've got a Windows 7 machine with LabVIEW 2012 and VIPM 2013 installed and running fine. I'm in the process of installing LabVIEW 2014 (from the PDS Disk Set). I installed LV2014, VIPM 2014, and a few toolkits. Everything looks OK. I also installed a few Urgent Updates suggested by NI Update. Several reboots. LabVIEW 2014 seems to be installed fine. When I click the VIPM icon, the Flash screen appears saying VIPM 2014 (Free Edition), lasts about a second, then vanishes, along with VIPM! I've just gone to the JKI Web Site and downloaded a copy of the VIPM 2014 installer. I'm going to try doing it "again", and see if it "takes" this time. I'll try to remember to report Success or Failure (well, if there's Failure, you can be pretty sure I'll report ...). Bob Schor
  15. I recently installed LabVIEW 2014 (32-bit) on a Windows 7 Pro (x64) machine that had VIPM 2014 already installed. I also have LabVIEW 2010 through 2013 installed on this same machine. I set up all of my LabVIEW versions with the same TCP/IP port, 3363, and "force" VIPM to accept this (so far, this has not been a problem). I just (for the first time) tried to install some packages (such as OpenG) on my 2014 system. To my surprise, on several installations, it would start, get about half-way done, then start the 2-minute Timer, apparently trying to connect to LabVIEW. When the timer expired, instead of an error message, I got a message "Successfully installed". And, indeed, if I stop LabVIEW and restart it, my packages show up in the palette. Why is VIPM "wasting my time" by making me wait two minutes per installation when the installation succeeds? Is this a Bug or a Feature? Bob Schor P.S. -- I'm running the Pro version of VIPM, if that makes a difference.
  16. I recently installed LabVIEW 2014 (32-bit) on a Windows 7 Pro (x64) machine that had VIPM 2014 already installed. I also have LabVIEW 2010 through 2013 installed on this same machine. I set up all of my LabVIEW versions with the same TCP/IP port, 3363, and "force" VIPM to accept this (so far, this has not been a problem). I just (for the first time) tried to install some packages (such as OpenG) on my 2014 system. To my surprise, on several installations, it would start, get about half-way done, then start the 2-minute Timer, apparently trying to connect to LabVIEW. When the timer expired, instead of an error message, I got a message "Successfully installed". And, indeed, if I stop LabVIEW and restart it, my packages show up in the palette. Why is VIPM "wasting my time" by making me wait two minutes per installation when the installation succeeds? Is this a Bug or a Feature? Bob Schor P.S. -- I'm running the Pro version of VIPM, if that makes a difference.
  17. Well, after several days of silence, I reopened my Surface and LabVIEW 2013 and "tweaked" various things that I didn't think mattered (like changing a firewall rule from "Auto" to "Allow", and enabling Scripting (which should not have mattered, I'd have thought). Maybe its the phase of the moon, but now it's installing.
  18. I'm having problems installing VIPM 13 on my Surface Pro (running Windows 8.1). This PC has LabVIEW 2012 and LabVIEW 2013 both installed. I had no trouble installing packages with LabVIEW 2012, but not with LabVIEW 2013. I have (successfully) used VIPM on multiple PCs (typically Windows 7) and multiple versions of LabVIEW (including, recently, a PC with LabVIEW 2010, 2011, 2012, and 2013). For all these machines (and the current Surface under discussion), all the versions of LabVIEW are set up identically -- TCP/IP enabled, Port 3363, all TCP options "on", localhost and enabled, all VIs enabled. I've rebooted this PC, then opened VIPM and navigated to the "Version" option. I chose 2013, then had it "Verify". It successfully opened LabVIEW 2013, but about 2-3 seconds later, gave an error message that I'll look up right now ... Here's what happens -- I open VIPM. select 2013 under Options, right-click, and and choose "Launch LabVIEW 2013". No problems. I then open Options, choose Configure LabVIEW Versions (for LabVIEW 2013), and click Verify. LabVIEW 2013 opens, then I get the error message "VIPM could not connect to LabVIEW 2013. Please verify the VI Server ...". On this screen, LabVIEW 2013 shows the correct port (3363), and, curiously, shows a checkmark in the Verified column. However, as I just noted, I cannot Verify (with the Verify button) nor can I install any packages. While it will be a (minor) pain, I'm willing to uninstall VIPM, wipe out its folders, and start all over. However, I'll wait to see if you have any suggestions. I'll also "play around" a bit, and if I succeed, I'll post a follow-up. Bob Schor
  19. I've been using TortoiseSVN for several years to manage my LabVIEW projects. It has been working so flawlessly for so many years that I am uncertain if I did any "magic" when I first installed it (I think my original client preceded Version 1.6). I just built a new PC, and installed the latest TortoiseSVN client, Version 1.8.2. Our repositories are still running the 1.7 SVN Services. Tortoise notes that Version 1.8 represents a new format for the Working Copy that is not back-compatible with earlier WC -- as I'm the only user of my Working Copies, this didn't seem to be a serious problem for me, even if different machines I use have different versions of SVN, as I never try to merge the WCs. I just did my first Update, and saw, to my shock, that Subversion said it was merging some of my changed VIs into my Working Copy. I never saw attempts to merge in the earlier releases -- instead, I would simply get updates or, in rare cases, conflicts (if I'd forgotten to update before making my own changes). In my panic, I accidently deleted the message from Subversion saying which files were "merged", so now I'm unsure what to do. I'm hoping that someone at JKI, where you have a TortoiseSVN "tool", has looked at the 1.8 client and how it interacts with LabVIEW. Based on my so-far single experience, it appears that it might not be able to tell that LabVIEW files are binaries, hence is trying to treat them as text. It is also possible that the "merge" message is false. I'd greatly appreciate your (collective) expert opinion. I've also posted a note on the NI Discussion Forums, so if you have a Solution or Recommendation, you might consider also posting it there in response to my query. Thanks for listening. Bob Schor
  20. A "Feature" of Easy Write XML File is that it errors out if the file already exists (i.e. if you need to overwrite a file). I urge you to add an optional Operation input to allow such an Overwrite to take place. True, the user could add code to (1) test if the file exists, (2) delete it if true, and (3) then do the Easy Write, but why require additional code, particularly if "inside" the protected VI you are doing an ordinary LabVIEW Open/Create/Replace file, and only need to change the operation from "Create" (the default) to "Replace or Create" (or to "Replace or Create with Confirmation"). If you did incorporate this change, it would be perfectly legitimate to raise an error for some other Operation input, of course.
  21. Quick followup -- on logging in again (not a Reboot, merely a Log Out), I found that the files I tried to Remove from the VIPC were still there (not a total surprise, as things "got stuck" after I clicked "Remove"). Also, the problem I had with the Start Menu disappearing was my own fault -- I'd mistakenly unlocked the Task Bar, and it was hidden along the top edge (instead of the bottom edge) of my window.
  22. I just installed (part of) LabVIEW 2013, which comes with VIPM 2013, to which I applied my Pro activation (seemed to "take"). I'm working on some code (doing documentation, fixing "spelling errors") that is distributed as a VIPC, and which installs its examples and some needed "utility features" (classes for generic plugins and some X Controls used to manage menus) in the local VIPM library. I wanted to strip out just the Class utilities, as I have an up-to-date version of the actual code. I open VIPM, go to Window and "Show VIP Configuration Editor", then (in VIPC Editor) "Open an existing VIPC". When it opens, it shows me a dozen Yellow Cubes ("The entire package is stored inside the configuration file"), but I can't do anything with them. In particular, half of them are OpenG packages that are already in the VIPM window, a third are the older versions of the files I'm working with, and only 2 or three are the files I want to install in my Package Library (the list that VIPM shows me). [it's always good to write complete documentation in a Forum, especially if you "write while doing". I was just going to say that if I right-click an entry and choose "Remove", nothing happens, but this time, it popped up a dialog and said something like "There are these other dependent packages here -- do you want me to remove them too?" I said "Yes", and then the "rest of the problem" popped up -- keep reading ...]. What happened this time is that the file and its associated dependents disappeared from the VIPC Editor window. At the same time, the cursor turned into the "spinning circle" ("Wait") cursor, and the Install Package and Uninstall Package icons in the VIPM toolbar started flashing at about 2 Hz. Needless to say, I cannot now exit either VIPM or VIPC Editor, except by using Task Manager to close the programs. In particular, neither Close button (X in upper right hand corner) works. I'm running this on a Windows 7 (x64, fully upgraded and patched). This machine is fairly new (built within the past month), and has relatively little software on it. I have installed LabVIEW 2012 SP1 and LabVIEW 2013, both with LabVIEW RealTime and the Report Generator Toolkit. Just for fun, I decided to see what happens if I re-run VIPM. I can't -- when I tried to close it, it somehow made the Windows Taskbar (at the bottom, with the Start button) disappear, and double-clicking on the VIPM shortcut on the desktop does nothing. I guess it's back to Ctrl-Alt-Del and asking Task Manager to reboot me. But first I'll send this off ...
  23. Some things in LabVIEW, like file sizes, are "naturally" typed as I64 (or U64). I just tried to write out some data that contained an I64 variable using EasyXML, and got an error message to the effect that "Element named "Bytes" is a I64 data type, which is not supported by the EasyXML toolkit.". While I can understand not supporting some of the "complex" LabVIEW types, I was surprised to see that this "basic" type generated an error. I'm hoping it's "something I ate", i.e. I might have a bad or old copy of EasyXML (VIPM identifies it as 2.0-2), or am just doing something wrong. Is this, in fact, a "feature" that 64-bit integers aren't supported? Can this be included in an update or new release? Or can you suggest a work-around? Bob Schor
  24. I just noticed something that makes a startling difference, and points out my less-than-complete understanding of XML and of EasyXML. If you look at the example code I sent you that "proves" my point, you'll notice it is completely "wrong" -- I have the "Read XML" function inside the For loop, so I'm opening the file over and over again, and extracting a single element, instead of the entire array. [incidently, if I remove the For loop, read once, and pass as the Type an Array of Clusters, the read takes less time than the write!]. What led me astray is an earlier use I made of EasyXML, where I was using it to write out Header information for experiment files. What I wanted in the Header file was a complete description of the experiment, including the "global" parameters (such as the subject's name, birthday, settings of the instrument, date and time, tester's name, etc.), trial-by-trial parameters (Trial number, specifics of the stimulus, subject's response), and a summary (total number of trials, ending time, etc.). I decided to use XML for this purpose, as it was "human-readable" (hence easy to check during development), portable, "standard", and (thanks to EasyXML) fairly simple to take into and out of LabVIEW, implementing cluster and arrays nicely. Because the data were being generated throughout the experiment, I wanted to write the header "as I went". Not knowing enough about XML, the approach I adopted was to use your Flatten and Unflatten routines, and to write an ordinary text file. Although the resulting file was not, I now understand, a "legal" XML file (lacking the <?xml> tag, since I didn't "know any better", it was something that I could parse easily and "fool myself" that I had an XML file. So when, in a completely different context, I decided to write out an array of clusters (which actually represented the walking of a directory tree) so I could analyze the data later, I thought of XML, and just decided to try NI's representation. I simply grabbed "Write XML to Data" and "Read XML from Data", not realizing the subtle difference between what I was doing now and what I did previously. I now (better) realize that your code may be perfectly OK, and the problem is my lack of understanding about "How to" do XML. So now I want to ask "How to do it". Here's what I want to do: 1) Generate a legitimate XML file, but one that does not need to be written "all at once" (which, it seems to me, is not a "requirement" for XML). I think this would require, in addition to "Easy Write XML File", an "Easy Open XML File" plus an "Easy Close XML File". Once the Open is accomplished, the user could simply use Easy Generate XML for each piece of data to be written, and simply write it as though it were a text file. 2) Read back and parse the resulting (legal) XML file. I'll note that it was easy to parse my "faux" XML file that I wrote using EasyXML, since I wrote out each element to a text file, so to parse it, I simply read in a line, which had the XML Start Tag, treated it as a variable name (which it was), found the End Tag, then knowing (from the Start Tag) the name (and therefore the type) of the variable, I could pass it to Easy Parse XML to do the work for me. For this to work for a "real" XML file, I would similarly need an "Easy Open XML File" (which, I suppose, could simply open the file as a text file for reading, and skip over the initial XML header tags until getting to the LabVIEW data section). It might possibly be useful to have an "Extract Element from XML File" that duplicates what I'm currently doing, that is, read a line, see if it has a Start Tag, if so read more lines until getting the End Tag, and return the resulting array to the user, with a signal (boolean, possibly) if the </LVData> end-of-XML tag is encountered. I look forward to discussing this with you all at NI week. Bob Schor
  25. Absolutely! You are doing things completely differently than I. I'm attaching my reworking of your code that definitively demonstrates the quadratic nature of the XML reading routine, contrasting it with the linear nature of the writing routine. The issue is the number of XML "records" in the file, not how many times you write a new file! Consider a text file -- if I write a text file of a million characters, I'd expect it to take 1000 times longer than to write a file of 1000 characters. Similarly, if I read a file of a million characters, I expect it to take 1000 times as long as a file of 1000 characters -- I expect the time to be linearly proportional to the size of the file. In the case of writing XML records, this proportionality is followed. It took me 3.9 seconds to write an array of 1000 "records", and 39 seconds to do 10,000 (see attached). However, when I read these two files, the 1000-record file took 21 seconds, but the 10,000-record file took >2400 seconds, or more than 100 times longer for a ten-times-larger file. I know what's wrong, and also know "how to fix it". I'd be happy to "tweak" the Easy Read XML File, but you'll need to "unlock" it for me (I have a purchased license for it). Bob Schor P.S. -- while running the attached Test routine, I noticed a strange behavior. As you'll see, I'm using the same file name for all the files. However, when I call Easy Write XML File and the file is already present, I get a LabVIEW error. Shouldn't there be an "open" option to allow you to open a file as read/write? Does the user need to precede the call to Easy Write XML File with a VI of her own to make sure that the VI does not already exist, and to delete it if it does? What is your idea about how to handle the various possibilities when getting ready to write an XML file? Test EasyXML Write and Read.vi
  • Create New...

Important Information

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