bugGNU Octave - Bugs: bug #44670, hgload can't open Matlab figures


bug #44670: hgload can't open Matlab figures

Submitter:  Guillaume <gyom>
Submitted:  Mon 30 Mar 2015 04:25:41 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Mon 29 Jul 2019 09:40:14 PM UTC, comment #39: 

Ah, yes.  It works quite nicely.  I checked the patch in under your credentials here (https://hg.savannah.gnu.org/hgweb/octave/rev/301186dbef68).

Rik <rik5>
Group administrator
Mon 29 Jul 2019 10:08:07 AM UTC, comment #38: 

To test the patch from comment #36, use the file testfig.fig attached to comment #30 and check whether the first and third listboxes have a contextual menu.

hgload ("testfig.fig");

uicontextmenu is indeed 'special' in the sense that specifying its parent is not enough and one also has to explicitly fill in the 'uicontextmenu' property of the parent as described in the note here:

Guillaume <gyom>
Mon 22 Jul 2019 11:27:26 PM UTC, comment #37: 

@Guillaume: Is there test code that I can use to verify your patch in comment #36?  It seems to me that the s_oct40.children.handle field is already assigned.

Rik <rik5>
Group administrator
Fri 19 Jul 2019 11:28:47 AM UTC, comment #36: 

This small change fixes the issue described in comment #30 about uicontextmenu: it is now assigned to the components whose handles are listed in the "special" field as per Matlab's behavior.

diff -r 378d3c91f85b scripts/plot/util/struct2hdl.m
--- a/scripts/plot/util/struct2hdl.m    Thu Jul 18 12:59:57 2019 -0400
+++ b/scripts/plot/util/struct2hdl.m    Fri Jul 19 12:24:04 2019 +0100
@@ -172,6 +172,9 @@
       s.properties = rmfield (s.properties, "extent");
     [h, s] = createui (s, par);
+    if (strcmp (s.type, "uicontextmenu"))
+      set (p(2, ismember (p(1,:), s.special)), 'UIContextMenu', h);
+    endif
     error ("struct2hdl: %s objects are not implemented yet", s.type);

Guillaume <gyom>
Thu 13 Dec 2018 09:31:43 PM UTC, comment #35: 

@Rik: Maybe we can restrict the scope of this report to implementing all base graphics objects.

The "special" field not being implemented correctly prevents us from handling axes labels. So I would say lets keep this report open until axes (and the special field) and uicontextmenus are fully functional.

As of today though, Octave can't open any Matlab figure file that contains graphics created with high level functions (even basic "plot")... but we could file another bug report about that.

Pantxo Diribarne <pantxo>
Group Member
Thu 13 Dec 2018 08:07:05 PM UTC, comment #34: 

Should we re-title this bug report or open a new one?  It seems that the remaining issue is the saving/loading of uicontextmenus.

Rik <rik5>
Group administrator
Mon 05 Nov 2018 05:34:51 PM UTC, comment #33: 

So far, I've been concerned with compatibility with Matlab figures (e.g. from a hgS_070000 struct) so the fix is in struct2hdl.m. From what I understand from Pantxo's comment #3 and comment #6, hdl2struct.m uses a different behavior for the "special" field (storing indices instead of handles):
so if a change was made to use Matlab mechanism, there would be a backward compatibility issue with figures saved by Octave (in a s_oct40 struct).

Guillaume <gyom>
Mon 05 Nov 2018 04:25:47 PM UTC, comment #32: 

For uicontextmenus, is a fix required in hdl2struct.m (to save things in the "special" list) AND in struct2hdl.m (to correctly recall them)?

Rik <rik5>
Group administrator
Mon 05 Nov 2018 04:20:16 PM UTC, comment #31: 
Rik <rik5>
Group administrator
Mon 05 Nov 2018 11:48:36 AM UTC, comment #30: 

Concerning my comment about uicontextmenu, I attach the fig file created with Matlab for the following figure:

h = figure;
u1 = uicontrol('parent', h, 'units', 'normalized', 'position', [0.3 0.1 0.4 0.2], 'style', 'listbox', 'string', 'listbox');
u2 = uicontrol('parent', h, 'units', 'normalized', 'position', [0.3 0.4 0.4 0.2], 'style', 'listbox', 'string', 'listbox');
u3 = uicontrol('parent', h, 'units', 'normalized', 'position', [0.3 0.7 0.4 0.2], 'style', 'listbox', 'string', 'listbox');

c = uicontextmenu;
uimenu(c, 'label', 'A');
uimenu(c, 'label', 'B');
uimenu(c, 'label', 'C');

set(u1, 'uicontextmenu', c);
set(u3, 'uicontextmenu', c);

savefig (h, 'testfig.fig');

The "special" field of the uicontextmenu contains the list of handles it applies to:

octave> load testfig.fig -mat
octave> hgS_070000.children(4).special # uicontextmenu
                ans =

octave> hgS_070000.children([1, 3]).handle # uicontrol
                ans =  9.0054
                ans =  11.005

(file #45362)

Guillaume <gyom>
Mon 05 Nov 2018 11:00:08 AM UTC, comment #29: 

Many thanks Rik, it works!

There is a semi colon missing here:

One issue I observe concerns a uicontextmenu that does not get attached to its parent uicontrol. It relates to this:
and I guess it touches upon Pantxo's comment #3 about the "special" field. From what I understand, in Matlab, the "special" field from a uicontextmenu contains the handle of the uicontrol it's the child of.

Otherwise I think we can close this bug report and open a fresh new one to discuss Pantxo's larger changes to hdl2struct/struct2hdl.

Guillaume <gyom>
Mon 05 Nov 2018 03:08:23 AM UTC, comment #28: 

I checked in the change to have struct2hdl work with uiXXX objects.  See https://hg.savannah.gnu.org/hgweb/octave/rev/a21d7d269472.  I had to remove the "extent" property from uiXXX objects before re-creating them since this property is read-only.  Because the processing of figures had become more complex I segregated the code off in to a new function createfigure().

What more needs to be done before we can close this report entirely?

Rik <rik5>
Group administrator
Sun 04 Nov 2018 05:33:32 PM UTC, comment #27: 

I applied the fix_open.patch here https://hg.savannah.gnu.org/hgweb/octave/rev/4f502f56664e.

I additionally modified it so that it checks for the .ofig extension whether an output is requested before deciding to call openfig.

-  elseif (any (strcmpi (ext, {".fig", ".ofig"})))
-    output = openfig (file);
-    drawnow ();
+  elseif (any (strcmpi (ext, ".ofig")))
+    if (nargout > 0)
+      output = openfig (file);
+    else
+      openfig (file);
+    endif

Rik <rik5>
Group administrator
Sat 03 Nov 2018 09:11:25 AM UTC, comment #26: 

A .fig file will be opened automatically with openfig.m (thanks to the custom extension implemented in bug #50543) so that line would never be reached with "ext" being ".fig".

Guillaume <gyom>
Sat 03 Nov 2018 04:37:53 AM UTC, comment #25: 

I reviewed the fix_open.patch.  Why is this line deleted from open.m?

-  elseif (any (strcmpi (ext, {".fig", ".ofig"})))
+  elseif (strcmpi (ext, ".ofig"))

Don't we want openfig to be called if the ".fig" extension is present?

Rik <rik5>
Group administrator
Wed 31 Oct 2018 12:20:33 PM UTC, comment #24: 

Thanks John and Rik for pushing and cleaning the new functions.

Concerning open.m, .fig files will now automatically be opened with openfig.m so no need to have specific code for it. For .ofig, we can either have an openofig.m wrapper around openfig.m (as suggested by Pantxo in comment #18), or leave it explicitly as it currently is. I attach relevant changes to open.m

I also attach a number of changes to struct2hdl.m that implement the following:

  • Figures are created invisible and set to visible at the end if required. This prevents flickering for invisible figures and allows for a faster load (as one doesn't see each element created one at a time).
  • The integerhandle property is used while creating a figure instead of being set afterwards. This prevents the figure handle to change, see bug #53342.
  • Support for ui* objects.
  • The other changes provide extra robustness for figures saved in matlab. They mainly correspond to checking that a given property exists before using it.

There is still a lot more to do, including merging changes from Pantxo in comment #6, but, with these changes, I observe a good compatibility with matlab *.fig files so it's an exciting step forward.

(file #45337, file #45338)

Guillaume <gyom>
Sat 27 Oct 2018 12:49:28 PM UTC, comment #23: 

I made a few changes pushed the changeset here:


Please take a look at this and let me know if I did the right thing with open.m.

John W. Eaton <jwe>
Group administrator
Sat 27 Oct 2018 10:09:51 AM UTC, comment #22: 

I don't remember all of the details and Pantxo will know better but I think that the new function openfig.m (uncommenting the call to movegui() as it's now available) and the changes to hgload.m from comment #13 can be pushed. The change to open.m is unnecessary now, after bug #53400. I would also make the change from comment #15 about copyobj.m.
There is still a lot of work to do but it should take place in struct2hdl.m.

Guillaume <gyom>
Fri 26 Oct 2018 08:31:39 PM UTC, comment #21: 

I also pushed the new savefig function from bug #53403.

John W. Eaton <jwe>
Group administrator
Fri 26 Oct 2018 08:23:09 PM UTC, comment #20: 

I pushed the movegui function from bug #53400.

Is the patch from from comment #13 OK to apply?

John W. Eaton <jwe>
Group administrator
Tue 15 May 2018 09:37:15 AM UTC, comment #19: 

@pantxo: yes, sure, it makes sense. I had forgotten about that other bug report. openfig also has a commented out call to movegui, now implemented in bug #53400.

Guillaume <gyom>
Mon 14 May 2018 09:49:26 PM UTC, comment #18: 

@gyom: I think for compatibility, open.m should be changed to support opening files on the basis of their extension, as proposed in bug #50543. I can rebase and finish the patch there, then "openfig.m" is automatically called for ".fig" files and we can add a "openofig.m" file (as a wrapper around your "openfig.m") that will handle default Octave figure extension. Is it OK?

Pantxo Diribarne <pantxo>
Group Member
Mon 14 May 2018 10:23:38 AM UTC, comment #17: 

@gyom: I'll be happy to help integrate your patches and make our figure loading/saving mechanism more robust and eventually ML compatible. Give me some time to take a look at this in the coming week.

Pantxo Diribarne <pantxo>
Group Member
Mon 14 May 2018 09:21:10 AM UTC, comment #16: 

@pantxo: with the 4.4 release out of the way, would it be possible to consider the patch in comment #13 ? I also have other related patches in bug #53403 and bug #53400, and others in preparation (eg about gui_mainfcn) that build on them. I would also be happy to work on refactoring struct2hdl.m following your suggestions.

Guillaume <gyom>
Fri 20 Apr 2018 01:57:28 PM UTC, comment #15: 

Adding this comment as a reminder that when hdl2struct/struct2hdl will have been upgraded to handle uicontrols, the following change will have to be made in copyobj.m:

diff -r affd44707573 scripts/plot/util/copyobj.m
--- a/scripts/plot/util/copyobj.m       Thu Apr 19 19:16:54 2018 -0700
+++ b/scripts/plot/util/copyobj.m       Fri Apr 20 14:46:12 2018 +0100
@@ -41,7 +41,7 @@
 function hnew = copyobj (horig, hparent = 0)

   partypes = {"root", "figure", "axes", "hggroup"};
-  othertypes = {"line", "patch", "surface", "image", "text"};
+  othertypes = {"line", "patch", "surface", "image", "text", "uicontrol"};
   alltypes = [partypes othertypes];

As it stands, the patch from comment #13  that includes changes in openfig.m, hgload.m and open.m is in my eye ready to be applied to the default branch.

Guillaume <gyom>
Thu 29 Mar 2018 04:44:26 PM UTC, comment #14: 

pantxo: managed to apply your patch with jordihg's help. I could open the figures fine with current's default. The two figures are identical apart from the colormap for the plot on the right (jet vs viridis).
I agree with the change in struct2hdl.m to have the figure created with visibility set to off to start with. Can we assume that the property will always be updated later on or should visible set to the default value if the field is not present in the input structure?

Guillaume <gyom>
Thu 15 Mar 2018 03:31:55 PM UTC, comment #13: 

I attach a patch implementing openfig.m as a wrapper around a slightly modified version of hgload.m (to support a second input, as in Matlab). It also includes changes to open.m.

Remaining changes for better support of Matlab figures will have to take place in struct2hdl.m; I started working on that following comments #6 and #7.

(file #43558)

Guillaume <gyom>
Tue 26 Sep 2017 06:34:27 AM UTC, comment #12: 

The OCTread_FIG.m function isn't as good as the modified OpenMatlabFigureInOctave.m.

I don't know about the license issue. Perhaps you can contact the owner of the github repository (https://github.com/rsnape/OpenMatlabFigureInOctave).

Roland Baudin <roland65>
Mon 25 Sep 2017 05:09:10 PM UTC, comment #11: 

An ?original? version of the file seems to be here, w/o a license:


I think we cannot accept files w/o a license.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 Sep 2017 11:38:57 AM UTC, comment #10: 

Just to mention that the function OpenMatlabFigureInOctave.m found at https://github.com/rsnape/OpenMatlabFigureInOctave works pretty well for opening a fig file in Octave.

The title, labels, legend, etc. are usually kept. I've seen some issues in complicated figures, but usually this function is better than the openfig.m provided here.

Perhaps, this function could be integrated to Octave?

Roland Baudin <roland65>
Tue 26 Jul 2016 03:58:08 PM UTC, comment #9: 

I just wanted to bring my portion of the discussion over from a duplicate bug I had created. That commentary is available in the linked "duplicate" bug, but I am reposting here to keep it in the same discussion.

As there have been various discussions on the maintainers mailing list about a method support a GUI builder, it made me start thinking about how I like the fact that the Matlab GUIDE only requires a FIG file and an associated M file as the underlying file format. Some people were in favor of the QTCreator ui files, which I am fine if that is the decision, but decided to try and get FIG files generated by Matlab to load in Octave.

I found a great website called undocumentedmatlab.com that explains that FIG files are just a MAT file that contains the figure information (see http://undocumentedmatlab.com/blog/fig-files-format). I think someone within Octave must have already known this because the hdl2struct and struct2hdl functions already are almost identical in underlying structure to the structure contained within a FIG file.

However, for the life of me I couldn't get struct2hdl to work for me in trying to load a Matlab-generated FIG file to load. There seemed to be a couple problems:
1) too many places where Octave's struct2hdl would fail if the FIG file struct didn't have properties named exactly the same as Octave was expecting.

2) struct2hdl wasn't handling the reading of the title, xlabel, ylabel, zlabel correctly. In the FIG struct, they are listed as children, but in the resulting axes handle these text handles need to be assigned to the corresponding property in the axes handle, rather than just added as children. It seems that Matlab does not add them as children, but does assign the handle to the appropriate axes property. It seems that Octave both adds them as children and assigns the handle to the appropriate axes property. The mapping for these non-regular children is handled with the "special" field of the axes sub-struct.

So, I wrote a fairly simple script that seems to be loading simple FIG files generated from Matlab into Octave. It recursively depth-first traverses the FIG struct, creates an object based on the handle type (not all are supported yet), and assigns any properties from the FIG struct that exist in the Octave handle. In the case where some of the children are irregular, the special field of the struct is used to determine the mapping from children to properties.

Is suspect the the Octave struct2hdl and hdl2struct are self-consistent, it is just that they don't handle the conversion from Matlab FIG struct to an Octave handle. I think the right approach is to try to fix up the existing struct2hdl and hdl2struct to be compatible with the FIG struct from Matlab, but am wondering if that will break a bunch of other people's code or existing figures that have been saved as structs in MAT files using the current Octave hdl2struct.

(file #38031, file #38032)

John Swensen <jpswensen>
Tue 26 Jul 2016 11:19:54 AM UTC, comment #8: 

@Guillaume: First of all I won't be able to work on this during the coming month, so feel free to test and propose modifications. Also could you attach a few ML figs (and the script you used to produce them) for testing ui* features but also regular plot/errorbar/log ...

>> figure: properties do not seem to be taken into account (Position, Name, MenuBar, ...).

Odd, I'll look into this

>> uicontrol: if an element does not have a style property, the default is "pushbutton" (see below).


>> uicontrol: for compatibility, a uicontrol frame could be changed into a uipanel (see below).

Or wait for frame to be implemented. There are already many ugly hacks in struct2hdl so unless the change uipanel/frame is transparent I'd prefer to avoid this solution.

>> uicontrol: each element is first displayed with default position (bottom left of the figure) then moved to its final location, which is slow.

Yes that is how most object are constructed. The reasoning behind this is that some children objects (I think of images in particular) may change the properties of their parent, so we first build a default parent object, build its children, and only then set its definite properties.

Pantxo Diribarne <pantxo>
Group Member
Tue 26 Jul 2016 10:30:31 AM UTC, comment #7: 

Thanks Pantxo, I just tried struct2hdl on a .fig file and it did work quite well. I have a few remarks:

  • figure: properties do not seem to be taken into account (Position, Name, MenuBar, ...).
  • uicontrol: if an element does not have a style property, the default is "pushbutton" (see below).
  • uicontrol: for compatibility, a uicontrol frame could be changed into a uipanel (see below).
  • uicontrol: each element is first displayed with default position (bottom left of the figure) then moved to its final location, which is slow.

Here are the small changes I made to the createui() subfunction:

function [h, s] = createui (s, par)
  if (isfield (s.properties, "style") && strcmp (s.properties.style, "frame"))
    s.type = "uipanel";
  switch s.type
    case "uicontrol"
      if (!isfield (s.properties, "style"))
        s.properties.style = "pushbutton";
      h = uicontrol (par, "style", s.properties.style);
      s.properties = rmfield (s.properties, "style");
      if (isfield (s.properties, "cdata") && isempty (s.properties.cdata))
        s.properties = rmfield (s.properties, "cdata");
    case "uipanel"
      h = uipanel (par);
    case "uibuttongroup"
      h = uibuttongroup (par);
      eval (sprintf ("h = %s (\"parent\", par);", s.type));
  addmissingprops (h, s.properties);

Guillaume <gyom>
Tue 26 Jul 2016 07:51:34 AM UTC, comment #6: 

Hi Guillaume,

I attached the modified hdl2struct/struct2hdl.m. Unfortunately I had started from old versions (hg id: e766f7f86c68) and didn't have time to rebase and ensure I did not reintroduce some fixed bug.

We those functions:

  • the format of figure structures is modified to be ML compatible: this probably means we should have two versions of each, one for reading/writing the old format, one for the new. For example the old version could be renamed _hdl2struct40_.m, the new _hdl2struct44_.m and then hdl2struct.m would be a wrapper around those.
  • support for ui* objects has been enabled
  • the simplest Matlab figures (plot, loglog, bar) can be open in Octave. Even though legends and colorbars are displayed correctly, like with Octave figures, they actually behave has independent axes (not very useful).
  • copyobj is 30% faster in some cases.

Testing against ML figure is as simple as:

s = load ("mlfigs.fig");
h = struct2hdl (s.hgS_070000, 0);

(file #38024, file #38025)

Pantxo Diribarne <pantxo>
Group Member
Fri 15 Apr 2016 11:36:28 AM UTC, comment #5: 

Hi Pantxo, do you have any updates on the hgload() front? I've been happily using my implementation of openfig() for a while now but it would be good to rely on your code. You mentioned that you already had a preliminary cset available - would you be able to find and share it?

Guillaume <gyom>
Tue 31 Mar 2015 05:43:18 PM UTC, comment #4: 

You're welcome to rename this bug report - my suggested implementation is far from clean and I'm sure building on struct2hdl is the way forward.
In the meantime I tried openfig with other .fig files and made some further adjustments (see new attachment), just in case it might be useful at some point. That made me notice two things that I reported elsewhere:

  • #44679 : segmentation fault with some .fig files when loading them in Octave
  • #44672 (point 5): accepting structures for property/value in GUI functions.

(file #33499)

Guillaume <gyom>
Tue 31 Mar 2015 04:18:34 PM UTC, comment #3: 

We don't want to duplicate efforts and that's why we implemented a structure similar (same fields) to Matlab one in the hope that struct2hdl would be able to handle both Octave and Matlab figures. Unfortunately I misinterpreted the "special" field and the current version is not compatible with Matlab figures.

I think I am the one who proposed the .ofig extension, maybe to avoid bug reports from users trying to open Matlab figs while we know we are not able to render them properly. You are right that the name of the variable in the structure is enough to know where the figure comes from and we should not restrict the extension (as we do with "run" function).

Would you agree if I retitle this bug report "hgload can't open Matlab figures" then we see what can be done/merged from your implementation of openfig?

Pantxo Diribarne <pantxo>
Group Member
Tue 31 Mar 2015 03:04:42 PM UTC, comment #2: 

Thanks for your comment. I came across hgload and struct2hdl not long after sending my initial comment...
If hgload can open a MATLAB .fig file then, yes, openfig could simply be a wrapper around it.
Looking at hgload, why using a new file extension .ofig instead of .fig? I thought it could be handled in the same way than .mat files, which can be MATLAB-compatible or not. Fields 's_oct40' vs 'hgS_070000' already specify software-specific content.

Guillaume <gyom>
Tue 31 Mar 2015 06:33:43 AM UTC, comment #1: 


Can you explain the difference between "openfig" function and "hgload". The latter is already implemented for use with Octave figure structures. It is currently not "allowed" to open Matlab .fig files as there are differences in the way the "special" field is handled in Octave and Matlab, but I have a preliminary cset somewhere in my computer that brings Octave in line with Matlab in this regard.
Also legend/colorbars and any object that has listeners on other parts of the figure won't work properly (this is also true for pure Octave figures).

Pantxo Diribarne <pantxo>
Group Member
Mon 30 Mar 2015 04:25:41 PM UTC, original submission:  

This is an initial attempt to implement the "openfig" function:


It is not complete but works for the *.fig files I am working with.

Guillaume <gyom>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #45362:  testfig.fig added by gyom (5KiB - application/x-xfig)
file #45337:  fix_open.patch added by gyom (868B - text/x-patch)
file #45338:  fix_struct2hdl.patch added by gyom (5KiB - text/x-patch)
file #43558:  openfig.patch added by gyom (9KiB - text/x-patch)
file #38031:  openfig.m added by jpswensen (2KiB - application/octet-stream)
file #38032:  SineWave.fig added by jpswensen (35KiB - application/x-matlab-figure)
file #38024:  hdl2struct.m added by pantxo (3KiB - application/vnd.wolfram.mathematica.package)
file #38025:  struct2hdl.m added by pantxo (24KiB - application/vnd.wolfram.mathematica.package)
file #33499:  openfig.m added by gyom (6KiB - text/x-matlab)
file #33493:  openfig.m added by gyom (4KiB - text/x-matlab)


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by roland65 (Posted a comment)
  • -email is unavailable- added by jpswensen (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by gyom (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-04 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-11-05 gyom Attached File- Added testfig.fig, #45362
    2018-11-04 rik5 Dependencies- bugs #38046 is dependent
    2018-10-31 gyom Attached File- Added fix_open.patch, #45337
        Attached File- Added fix_struct2hdl.patch, #45338
    2018-10-27 jwe StatusNone Ready For Test
    2018-03-15 gyom Attached File- Added openfig.patch, #43558
    2016-07-26 jpswensen Attached File- Added openfig.m, #38031
        Attached File- Added SineWave.fig, #38032
    2016-07-26 pantxo Dependencies- bugs #48586 is dependent
    2016-07-26 pantxo Attached File- Added hdl2struct.m, #38024
        Attached File- Added struct2hdl.m, #38025
    2015-04-04 pantxo SummaryImplementation of the &quot;openfig&quot; function hgload can't open Matlab figures
    2015-03-31 gyom Attached File- Added openfig.m, #33499
    2015-03-31 pantxo CategoryGUI Plotting
    2015-03-30 gyom Attached File- Added openfig.m, #33493

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code