Page 1 of 1
FFcount () and FFirst ()
Posted: Thu Nov 15, 2018 3:00 pm
by Karl-Heinz
Hi Robert,
are there currently open tickets for FFcount () and FFirst () ?
regards
Karl-Heinz
FFcount () and FFirst ()
Posted: Thu Nov 15, 2018 4:49 pm
by robert
No open tickets
Robert
FFcount () and FFirst ()
Posted: Fri Nov 16, 2018 2:01 pm
by Karl-Heinz
Hi Robert,
i´ve noticed a few problems with ffcount() and ffirst()
- Only of the very first item found, the fname() etc. content is shown
- missing exception handling / Ferror()
- directories are found but not added to the foundEntries list
- die param of oDirfiles:Getfiles() should be the cMask and not the filespec var
Before you start the app create the dir
D:test
and add some subdirs to D:test. Also copy some .txt files to D:test
The ffcount.prg content is a subset copy of the GitHub filesearch.prg . All changes i´ve made are marked with KHR. Currently the content of the ffcount.prg is deactivated. So if you run the unchanged app you´ll see a errorcode 87 Exception. When you remove the /*..*/comment markers in the ffcount.prg, ffcount() and ffirst() behave as expected.
regards
Karl-Heinz
FFcount () and FFirst ()
Posted: Fri Nov 16, 2018 4:37 pm
by Chris
Hi Karl-Heinz,
Thanks a lot! All problems confirmed and your fixes look very good to me, too. I only have not followed closely the discussion about error handling, so I'll let Robert comment on that. In the code you have added a comment to use setErrorState(e) instead of FError().
Chris
FFcount () and FFirst ()
Posted: Fri Nov 16, 2018 4:57 pm
by robert
clearErrorState() and setErrorstate() not only record the FError() number but also save the last Exception which can be retrieved with FException().
So I would prefer to call these 2 methods in stead of the FError() function.
Karl-Heinz could not call these in his code because they are internal to XSharp.Core.
Robert
FFcount () and FFirst ()
Posted: Fri Nov 16, 2018 10:25 pm
by Chris
OK, changes are committed now, Karl-Heinz thanks for your contribution! Just needed to make some further changes regarding directories, to include both dirs and files when FA_DIRECTORY is specified.
FFcount () and FFirst ()
Posted: Sat Nov 17, 2018 11:02 am
by Karl-Heinz
i compiled the sample with the lasted (2.0.0.7) build, but i still see an XS0118 error as in 2.0.0.5.
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
Compilation failed (4 errors)
steps to reproduce the errors:
1. rename in XIDE the assembly name from "ffcounter" to "ffcount"
2. deactivate the complete ffcount.prg content.
now you should get the XS0118 errors. It seems the compiler gets confused about the "FFCount" usage ?
regards
Karl-Heinz
FFcount () and FFirst ()
Posted: Sat Nov 17, 2018 1:09 pm
by Chris
Karl-Heinz wrote:i compiled the sample with the lasted (2.0.0.7) build, but i still see an XS0118 error as in 2.0.0.5.
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
error XS0118: 'FFcount' is a namespace but is used like a variable Start.prg
Compilation failed (4 errors)
steps to reproduce the errors:
1. rename in XIDE the assembly name from "ffcounter" to "ffcount"
2. deactivate the complete ffcount.prg content.
now you should get the XS0118 errors. It seems the compiler gets confused about the "FFCount" usage ?
Yeah, there still do exist some known problems with naming conflicts like that, you cannot use an assembly name which is the same with a function or class name (specific problem is that the compiler generates a class named "FFCount.Functions" for holding functions and globals).
It's on the list to fix those in the compiler (in addition to many similar that Robert has already fixed), but with low priority since they are very complicated to fix and there's a relatively easy workaround, for now please just use a different assembly name.