Gianni The approach I took for .NET was ... (And this is the first time I have done this so was a bit of a learning exercise) Again .... very likely better ways to achieve this.
Create a .NET DLL and use in VFP. Primary reference here: http://www.tek-tips.com/faqs.cfm?fid=3836 (bit out of date) 1. Using Visual Studio .NET create a C# Class Library project – named Utilities 2. Add reference to “System.EnterpriseServices” 3. Code the Class e.g. using System; using System.Text; using System.Linq; using System.Runtime.InteropServices; using System.Collections.Generic; using System.Threading.Tasks; namespace Utilities { public class FileInfo : System.EnterpriseServices.ServicedComponent { public Int32 LineCount(String FilePath) { int count = System.IO.File.ReadLines(FilePath).Count() ; return count; } } } 4. Create key pair (To sign the assembly). In my case I used (from an Admin command window): CD “c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin>” sn -k Utilities.SNK Returned: Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Key pair written to Utilities.SNK 5. Copy the SNK file to the DLL build directory. 6. Edit Assembly.cs file. Change the entry [assembly: ComVisible(false)] to [assembly: ComVisible(true)] Ignore the [assembly: AssemblyKeyFile("")] step in Craig’s tip. Instead add the SNK file in the “Signing” section per step 7. 7. Under properties of the project select “Signing” • Check “Sign the assembly” • Type in the “Key File name:” in this case Utilities.SNK • I de-selected “Protect my key file with a password” – too many to remember already. 8. Build the Solution in Visual Studio 9. Register the assembly. (from Admin command prompt) CD “C:\Windows\Microsoft.NET\Framework\v4.0.30319” regasm.exe D:\VFP9\apps\c#\Utilities\Utilities\bin\Release\Utilities.dll /tlb /nologo /codebase Returned: Types registered successfully Assembly exported to 'D:\VFP9\apps\c#\Utilities\Utilities\bin\Release\Utilities.tlb’, and the type library was registered successfully C:\Windows\Microsoft.NET\Framework\v4.0.30319> 10. Then to use it in VFP .. oUtil = CREATEOBJECT("Utilities.FileInfo") nLines = oUtil.LineCount(<FilePath>) -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Gianni Turri Sent: Saturday, 29 April 2017 2:24 AM To: profoxt...@leafe.com Subject: Re: Getting count of rows in a text file -- best approach? Test file of 1.67 GB correctly managed by FSO but not by VFP9 SP2 that gives Error 43 (There is not enough memory to complete this operation). Test file of 5.31 GB correctly managed by FSO but not by VFP9 SP2 that gives Error 1103 (Invalid seek offset). FSO method counts chr(10) / LF characters. alines() by default counts the occurrences of chr(10) plus the occurrences of chr(13) minus the occurrences of chr(13) + chr(10) Please tell us more about the FLL and the code you used! Gianni On Sat, 29 Apr 2017 01:15:06 +1000, "Darren" <fox...@ozemail.com.au> wrote: Many ways to do this. I've compared 3. With a text file 350Mb | 5.3Million lines . Each method reported same # of lines. Timing done with high resolution timers so reasonably accurate. ... 1. C++ FLL 0.4064 seconds 2. C# .NET 1.2779 seconds : Tip on how to do this is at http://www.tek-tips.com/faqs.cfm?fid=3836 3. FSO 7.3874 seconds : (using OpenTextFile etc.) With a text file 2.6GB file. | 42 Million lines. FSO died - reported no lines and finished in 0.0002 seconds - other two methods reported accurately. 1. C++ FLL 3.2426 seconds 2. C# .NET 10.0600 seconds 3. FSO 0.0002 seconds : FAILED So I'd guess if you are doing many of these and time is an issue then perhaps a FLL approach might be beneficial. Certainly if file is large enough (probably hits the 2Gb limit in VFP) then FSO is not an option. -----Original Message----- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Gianni Turri Sent: Friday, 28 April 2017 11:39 PM To: profoxt...@leafe.com Subject: Re: Getting count of rows in a text file -- best approach? Ok. Anyway this is the slower method: loFSO = createobject("Scripting.FileSystemObject") loFile = loFSO.OpenTextFile(m.filename, 1) do while ! loFile.AtEndOfStream() loFile.SkipLine() enddo ? loFile.Line -1 Gianni On Fri, 28 Apr 2017 15:29:48 +0200, "Fernando D. Bozzo" <fdbo...@gmail.com> wrote: >Forget my comment, I've tested it and works beautifully :) > >2017-04-28 15:24 GMT+02:00 Fernando D. Bozzo <fdbo...@gmail.com>: > >> Gianni, you skipped something very important, the part that skip the >> lines so the Line property is updated: >> >> 'Skip lines one by one Do While txsInput.AtEndOfStream <> True >> txsInput.SkipLine ' or strTemp = txsInput.ReadLineLoop >> >> 2017-04-28 15:08 GMT+02:00 Gianni Turri <gianni...@gmail.com>: >> >>> On Thu, 27 Apr 2017 17:12:49 +0200, "Fernando D. Bozzo" < >>> fdbo...@gmail.com> wrote: >>> >>> >Hi Mike: >>> > >>> >A very fast method is using the FileSystemObject: >>> > >>> >loFSO = CREATEOBJECT("Scripting.FileSystemObject") >>> >loFile1 = loFSO.OpenTextFile(lcArchivo1, 1) >>> > >>> >Look at the syntax on Microsoft web site for the read method. >>> >It does not have the limitation of VFP's fread/fgets >>> >>> loFSO = createobject("Scripting.FileSystemObject") >>> >>> loFile = loFSO.OpenTextFile(m.filename, 8, .f.) ? loFile.Line -1 >>> >>> This method overcome VFP memory / file size limits. >>> >>> Source: >>> http://stackoverflow.com/questions/7416553/function-to-count-number- >>> of-lines-in-a-text-file [excessive quoting removed by server] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/008801d2c07e$76f47430$64dd5c90$@ozemail.com.au ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
