Back to the main page.
Bug 2473 - ft_databrowser: crash when using preproc window containing vector more than once
| Status | CLOSED FIXED |
| Reported | 2014-02-14 09:49:00 +0100 |
| Modified | 2021-09-16 14:05:07 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | Jim Herring |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2314 |
| See also: |
Jim Herring - 2014-02-14 09:49:04 +0100
Created attachment 592 preproc_window1 When supplying a vector in ft_databrowser's preproc window, the layout/format of the vector is changed after saving and closing so that the square brackets end up in separate lines from the numbers. For example, see attached figure 'preproc_window1' for the preproc window before saving and closing and see figure 'preproc_window2' for the preproc window after reopening the preproc window again. Clicking on 'save and close' then results in a crash.
Jim Herring - 2014-02-14 09:49:46 +0100
Created attachment 593 preproc_window2
Jan-Mathijs Schoffelen - 2014-03-06 15:46:54 +0100
Assigned to a named person, to keep this on the radar. Could you provide a test-script for this? This could get us started debugging. Please, also add this one to the dependency of the mother of all databrowser bugs.
Jim Herring - 2014-03-20 09:28:33 +0100
I had already added this bug to the dependency of the MOFB, or did I miss something? I've created a test script that loads some data and opens the databrowser although I did not think it to be useful at first as the error seems to be produced somewhere in the databrowser ui. I don't know how to access the pushbutton callback from outside of ft_databrowser.m.
Jim Herring - 2014-03-24 13:55:32 +0100
The error seems to result from printstruct printing the cfg.preproc structure 'wrong'. I'll look further into it.
Jim Herring - 2014-03-24 15:50:54 +0100
printmat, which is called by printstruct seems to parse the key-value pair 'cfg.preproc' and [3 45] by first printing the 'cfg.preproc' part, followed by adding '=[', forming a new line, then adding '3 45', followed by a new line with ']'. Turning 'cfg.preproc = [3 45]' into: 'cfg.preproc = [ 3 45 ]' The function is quite small: function str = printmat(name, val) siz = size(val); if prod(siz)==0 str = sprintf('%s = [];\n', name); elseif prod(siz)==1 str = sprintf('%s = %s;\n', name, printval(val)); elseif numel(siz)==2 str = sprintf('%s = [\n', name); for row=1:siz(1) for col=1:siz(2) str = sprintf('%s %s', str, printval(val(row,col))); end str = sprintf('%s\n', str); end str = sprintf('%s];\n', str); else str = sprintf('%s = %s;\n', name, printval(val)); end
Jim Herring - 2014-03-25 15:17:50 +0100
In principle evaluating the code produced by printmat does work in the command window. However, ft_databrowser checks whether each line contains 'cfg.preproc' and it adds a semicolon to each line which makes it impossible to evaluate any value that is spread over multiple lines (although it seems reasonable to allow this).
- 2014-03-26 13:20:14 +0100
FT-meeting discussion: the problem should be solved at the level of databrowser: the error-catching mechanism should be user-friendly and robust.
Jim Herring - 2014-04-01 12:57:22 +0200
Although the main problem related to this bug seems to be related to ft_databrowser, I wonder whether printmat behaves as desired. Printmat prints, for example, [1 2 3] as: [ 1 2 3 ] Shouldn't printmat print [1 2 3] as it is?
Robert Oostenveld - 2014-04-01 13:48:45 +0200
(In reply to Jim Herring from comment #8) I think that either one could be considered as correct. Printing it as one-liner would be visually more appealing though. I adjusted it for you mac011> svn commit printstruct.m Sending printstruct.m Transmitting file data . Committed revision 9326. Note however that it is now not fully consistent with numeric and cell-arrays: >> a = [1 2 3]; >> printstruct(a) ans = a = [ 1 2 3 ]; >> b = {1, 2, 3}; >> printstruct(b) ans = b = { 1, 2, 3 }; Also the comma's are different. I don't know why there are comma's in the first place.