Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/mantidproject/mantid.git. Pull mirroring updated .
  1. Dec 11, 2017
  2. Oct 26, 2016
  3. Feb 20, 2016
  4. Feb 19, 2016
  5. Feb 18, 2016
  6. Feb 13, 2016
  7. Oct 05, 2015
  8. Dec 16, 2014
  9. Dec 04, 2014
  10. Sep 01, 2014
  11. Aug 29, 2014
  12. Aug 15, 2014
  13. May 28, 2014
  14. Oct 18, 2013
    • Russell Taylor's avatar
      Re #8159. Make sure the filename property's name is set correctly. · b289687e
      Russell Taylor authored
      In the case of LoadEventPreNexus is is "EventFilename". It seems that for
      everything else is is "Filename" because the variable that holds this is
      empty by the time the algorithm comes to run (though the loader is
      selected correctly).
      I've factored out the method that sets the variable and called it again
      from within a method that exec() calls.
      b289687e
  15. Jul 04, 2013
  16. Apr 02, 2013
  17. Jan 02, 2013
  18. Nov 19, 2012
  19. Nov 02, 2012
  20. Oct 15, 2012
  21. Jul 29, 2012
  22. Jul 27, 2012
    • Peter Parker's avatar
      Refs #5205 - Revert multifile stuff for now. · 4fe9cd9d
      Peter Parker authored
      This reverts commit a9c8a59a.
      4fe9cd9d
    • Peter Parker's avatar
      Refs #5212, #5441 - Better parsing when multifile loading. Hist Fixed. · 5b78e0e5
      Peter Parker authored
      Allow filenames specified with the format <<short><operator>>...<short>
      where:
      
      <short> = <dir><inst><underscore><runs><ext>
      <operator> = "+" or ","
      <runs> = lists and/or ranges of (possibly added) runs e.g. "12,13+14,15:20".
      
      See header file of MultipleFileProperty for more info on syntax.
      
      This enables workspaces loaded through the algorithm to have a history that
      can be used to reproduce the workspace properly.
      
      MWRunFiles widget of LoadDialog now remembers the exact text a user typed -
      in this way any user who types "INST0-50", clicks "Run" and reopens the
      dialog is not met by a huge string containing a list of all 51 fully
      resolved files, but rather their original input.
      
      Changed the vector<vector<string>> templated versions of the toString and
      toValue functions to accept customised delimiters.  This enables us to add
      an option for the user to turn off multifile parsing if they are crazy
      enough to want to load files with a plus or a comma in their path.
      
      Changed the inner workings of Load for multi files.  No longer calling sub
      algorithms with setChild or alwaysStoreInADS.  All workspaces are
      essentially created outside the ADS and managed by the algorithm, right up
      until the OutputWorkspaces are set.
      
      Tests added where appropriate, but the majority of parsing cases are already
      covered by MultiFileNameParser.
      5b78e0e5
  23. Feb 14, 2012
    • Peter Parker's avatar
      Refs #1419 - Changes to finally support multi file loading. · 6039c89a
      Peter Parker authored
      MultiFileProperty changed to store a vector of vectors of file names. File
      names that share a vector are to be added. Old functionality can be produced
      by calling "flattenFileNames".  See source code for more info.
      
      MultiFileProperty was used in one place previously (MDMergeFiles), this has
      been modified to relect these changes.
      
      Load now implemented in terms of MultiFileProperty, though its interface is
      unchanged.  "Filename" input is now parsed as a multi file, and if that
      fails old functionality is attempted.  Error reports will output the result
      of both attempts.
      
      Some additional template specialisations / "toString" overloads
      surrounding the Property class heirachy were necessary to properly support
      std::vector<std::vector<std::string> >.
      6039c89a
  24. Oct 25, 2011
  25. Sep 29, 2011
  26. Sep 18, 2011
  27. Jul 11, 2011
    • Roman Tolchenov's avatar
      1) I don't think anything should be done here as fast algorithms may not be... · 8a27bd96
      Roman Tolchenov authored
      1) I don't think anything should be done here as fast algorithms may not be possible to cancel anyway.
      2) Made Algorithm::cancel() method virtual and overridden it in Load to call cancel() on the concrete loader. A test file can be sans2d00005512.nxs.
      3) MantidPlot makes sure that the AlgorithmDockWidget is visible when an algorithm is running. fixes #1733
      8a27bd96
  28. Apr 15, 2011
  29. Apr 12, 2011
  30. Mar 02, 2011
  31. Feb 15, 2011
  32. Feb 09, 2011
  33. Feb 08, 2011
  34. Feb 02, 2011
  35. Feb 01, 2011
  36. Dec 29, 2010
Loading