Detective work on built executables
Hi Will, You have probably already tried the obvious, but in case you haven't, try a detailed analysis of the OS timestamps assigned to each file. Although the two are not always related, it may just be that the executable was created immediately following an update to the top level vi. If you are using llb's the problem should be simple but it sounds as though your predecessor used dynamic vi calling and therefore timestamp of the files may be an important clue - look for the most recently updated vi, prior to the .exe's being created. Regards, Chris Harden Test System Design Engineer. FR HiTemp Ltd, Brook Road, Wimborne, Dorset. UK. BH21 3RD. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Keogh Sent: Thursday, June 03, 2004 3:44 PM To: Info-Labview Subject: Detective work on built executables Dear built-executable gurus, I have an ugly labview problem. I have inherited a suite of labview programs, consisting of built executables that are known to work, and a vast, disorganised pile of vis. The challenge is to reconstruct working versions of the source code corresponding to each executable. What makes it hard is that there are 1/2 doz different versions of each vi, and no obvious way to tell which are the 'good' ones. I am hoping that it may be possible to dig into the exes and find out what vis went in to them (I understand that I certainly can't get the original source code out of the exes, but any clues would be helpful). Does anyone have any ideas? Thanks, Will Will Keogh Borehole Research Group Lamont Doherty Earth Observatory of Columbia University 61 Route 9W, Palisades NY 10964, USA Ph: 845-365-8673 Fax: 845-365-3182 [EMAIL PROTECTED] This e-mail and any files transmitted with it (E-mail) is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version
RE: Not quite off-topic: List misuse
List, I disagree - targeted emails that are specific to LV or NI users can be useful in bringing ones attention to products that may otherwise remain undiscovered (don't know if this one was, didn't see it). Especially useful where advertised products are cheaper and possibly offer better functionality than similar NI products. I have been especially appreciative of certain low cost DAQ products that have come to my attention via the list. I do however agree that totally unrelated advertisements are a no no. Regards, Chris Harden. Test System Design Engineer. FR-HiTEMP Ltd, Brook Road, Wimborne, Dorset. UK. -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] On Behalf Of Rochefort, Paul Sent: Friday, May 28, 2004 6:48 PM To: 'Tore Johnsen'; Info-Labview (E-mail) Subject: Not quite off-topic: List misuse I was not on the spam list but I agree with Tore Paul A. Rochefort AECL Chalk River Laboratories -Original Message- From: Tore Johnsen [ mailto:[EMAIL PROTECTED]] Sent: May 28, 2004 13:12 To: [EMAIL PROTECTED] Subject: Not quite off-topic: List misuse Dear list, I recently received a full-blown advertisement (SPAM) from a company that uses THIS LIST to gather email addresses. The sender is a member of the list: John Toto at Superlogics. I don't at all mind members peddling their products in direct response to questions posted to the list (as John has done before). That can actually be quite helpful. However, when it degenerates into full-blown full-page unsolicited advertisements with all the bells and whistles sent directly to members of the list - well that's when I make a NEVER BUY FROM entry in the list I keep for that purpose. Sorry John: Gotta try to nip this in the bud before it degenerates further. - Tore This e-mail and any files transmitted with it (E-mail) is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version
RE: LabVIEW to Excel wierdness
Hi Alvin, Sounds to me like you need to try and get back to a system that runs your original setup, i.e. Excel 2000 whatever OS you previously used. I have some experience of ActiveX calls to Excel, but have not yet tested old apps with the new version of Excel. My suspicion would be that it is the Excel upgrade that has caused this issue. It also sounds like part of the problem is that the file itself is not opening - can you set the ActiveX property to 'visible' so that you can prove to yourself that the file is correctly opening before going any further with your investigations? Best wishes, Chris Harden. Test System Design Engineer. -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 18 March 2004 16:45 To: [EMAIL PROTECTED] Subject: LabVIEW to Excel wierdness Dear Folks, I have a LabVIEW app that writes report data out to disk as a tab-delimited text file, then triggers an Excel macro. The excel macro is an auto-open macro, so I have a vi which opens the macro.xla file, then an ActiveX call from LV that tells Excel to run the auto-open macro. This has worked fine in the past, for previous projects, but on a recent project (in which I copied over the same vi's from the old project) I could not get it to work. Now labview opens the text file in excel, opens the macro.xla file, then instead of running the macro Excel just closes both files and nothing seems to happen. I tried several different things with timing, thinking maybe the text file wasn't completely open when the macro was triggered, or some such, but to no avail. I put a pop-up message box in the macro at the start, and that works, it pops up, but after I dismiss it I see the same behavior. This morning, I loaded my old app, and to my surprise it no longer worked either. The only change in Excel is I recently upgraded to Office XP, so now it is Excel 2002 vs maybe Excel 2000 before. I have had to fiddle with the ActiveX calls before for changes in Excel, but I tried all the usual fiddling (delete and redrop the invoke/property nodes, change the property to something else and back again, recompile the vi) made no difference. Does anyone else have any experience with this? I am really doing very little with ActiveX, just having Excel open a text file, open a macro file, and run the xlauto_open macro, then waiting until the number of open worksheets goes to 0 so I can close Excel. Thanks in advance, Alvin Alvin W. Moore Jr. Measurement Systems Programmer Research, Development, and Engineering Corning Cable Systems Hickory, NC This e-mail and any files transmitted with it (E-mail) is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version
RE: Application builder and LabVIEW base package
Hi Ian, I'm not sure about LV7 but I know that the apps builder works with the base package versions of LV5 6/6.1 which I currently use. Hopefully this is not a requirement of LV7 - this would be a retrograde step. Regards, Chris Harden. Test System Design Engineer. FR-HiTEMP Ltd, Brook Road, Wimborne, Dorset. BH21 2BJ. -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED] On Behalf Of Ian G Williams Sent: Thursday, April 08, 2004 7:02 AM To: Info-LabVIEW list Subject: Application builder and LabVIEW base package Where I am working we currently use the LabVIEW 7 Express base package. We need to distribute some minor apps I have written with this to other machines and so I thought buying the App Builder would solve the problem. However, the website seems to hint the full dev. system is needed. Does anyone know if the apps builder works with the base package, as long as the app only uses subVIs from the base package itself? It's only a file manipulation routine, no DAQ or anything. Thanks in advance... Ian G Williams Warwick Technology Limited Warwick UK http://www.warwicktech.co.uk --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 06/04/04 This e-mail and any files transmitted with it (E-mail) is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version
