Back to the main page.
Bug 1536 - ft_getopt fails on windows 64 bit
| Status | CLOSED FIXED |
| Reported | 2012-06-18 14:07:00 +0200 |
| Modified | 2019-08-10 11:56:01 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 major |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 1407 |
| See also: |
Robert Oostenveld - 2012-06-18 14:07:47 +0200
see http://bugzilla.fcdonders.nl/show_bug.cgi?id=1407#c26 The problem is not specifically related to the EGI, but seems a generic issue. Therefore I made this bug out of it ----- I've looked into why if I try to read an event with v2, v1 is still used. I call read_event as follows: event_v2 = ft_read_event('C:\Users\Ingrid\Documents\EGI_hdEEGdocs\MFF_API_2012-04-09\testfiles\Long64ChannelWithEvents.mff', 'headerformat', 'egi_mff_v2') However on line 109 in ft_read_event, eventformat comes back empty: % get the options eventformat = ft_getopt(varargin, 'eventformat'); and therefore gets set to v1 in line 112 if isempty(eventformat) % only do the autodetection if the format was not specified eventformat = ft_filetype(filename); end I tried to debug the ft_getopt function, to see why it doesn't return eventformat = 'egi_mff_v2', but when I put a debugging stop, I get the popup message that it's shadowed by ft_getopt.mexw64 file. Could this explain the different behavior on different systems?
Robert Oostenveld - 2012-06-18 14:15:02 +0200
(In reply to comment #0) @Ingrid, could you try out the test code in http://code.google.com/p/fieldtrip/source/browse/trunk/test/test_ft_getopt.m which you should also find in your local svn copy. We don't use win64 that much, so the specific mex file could be the problem. You can also try by deleting the mex file and use the m-file implementation instead. They should result in the same output, but the mex file should be the (much) faster one. Note that these mex files and the ft_getopt.m are in many different xxx/private directories (and also in utilities), so make ure you don't mix up the different copies when testing. @Jorn (CC), could you also check this on your 64 bit windows?
Jörn M. Horschig - 2012-06-18 15:29:01 +0200
I'm using win64 most of the time and it works for me (as well the testscript as everything else I am doing with FT). May be related to the fact that I got visual studio installed?
Ingrid Nieuwenhuis - 2012-06-18 18:32:20 +0200
There was no problem with the getopt mex file. The problem was, I called the ft_read_event with "headerformat' not with 'eventformat' ft_read_event('C:\Users\Ingrid\Documents\EGI_hdEEGdocs\MFF_API_2012-04-09\testfiles\Long64ChannelWithEvents.mff', 'headerformat', 'egi_mff_v2') Note, I've also ran the test_ft_getopt.m, works all ok.
Ingrid Nieuwenhuis - 2012-06-18 18:33:17 +0200
There was no problem, see comment 3
Robert Oostenveld - 2019-08-10 11:52:06 +0200
This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on https://github.com/fieldtrip/fieldtrip/issues.