Introduce a helper for OPENFILENAME struct to make certain logic testable.

ui/base/win/open_file_name_win.h

+// Copyright (c) 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef UI_BASE_WIN_OPEN_FILE_NAME_WIN_H_
+#define UI_BASE_WIN_OPEN_FILE_NAME_WIN_H_
+
+#include <Windows.h>
+#include <Commdlg.h>
+
+#include <vector>
+
+#include "base/macros.h"
+#include "base/strings/string16.h"
+#include "base/tuple.h"
+
+namespace base {
+class FilePath;
+}  // namespace base
+
+namespace ui {
+namespace win {
+
+// Encapsulates an OPENFILENAME struct and related buffers. Also provides static
+// methods for interpreting the properties of an OPENFILENAME.
+class OpenFileName {
+ public:
+  // Initializes the OPENFILENAME, which may be accessed using Get(). All fields
+  // will be NULL except for |lStructSize|, |lpstrFile|, and |nMaxFile|. The
+  // file buffer will initially contain a null-terminated empty string.
+  OpenFileName(HWND parent_window, DWORD flags);
+  ~OpenFileName();
+
+  // Sets |lpstrInitialDir| and |lpstrFile|.
+  void SetInitialSelection(const base::FilePath& initial_directory,
+                           const base::FilePath& initial_filename);
+
+  // Returns the single selected file, or an empty path if there are more or
+  // less than one results.
+  base::FilePath GetSingleResult();
+
+  // Returns the selected file or files.
+  void GetResult(base::FilePath* directory,

[sky, 2014/07/31 16:27:31]

const FilePath&? Also, is there a reason you separate out the directory and file
name? Seems easier to not have to combine the paths (for example,
GetSingleResult doesn't separate out the directory from the name).

[erikwright (departed), 2014/07/31 16:39:29]

Both parameters are out-parameters, unless this is your suggested return type
(see below).
In the follow-up CL you will see that I use this to marshal the results across
IPC. If I retrieve a vector of absolute file paths I need to do checks to make
sure that they are all in the same directory and have failure cases otherwise
(in order to re-serialize the result back into an OPENFILENAME).

While it might be better to just keep the result in some Chrome-specific
datastructure and not worry about this constraint of OPENFILENAME, at the moment
I can't do that. First and foremost because I want to maintain API compatibility
so that I can A/B test the utility-process based implementation against
::GetOpenFileName to measure its impact on stability.

+                 std::vector<base::FilePath>* filenames);
+
+  // Returns the OPENFILENAME structure.
+  OPENFILENAME* Get();

[sky, 2014/07/31 16:27:31]

nit: inline this and name it name it to match field name.

[erikwright (departed), 2014/08/01 13:26:09]

Renamed to GetOPENFILENAME(). Which seems a little unorthodox.

But GetOpenFileName would be not only confusing but probably fail to compile
because (1) that is the windows method name the structure is intended to be used
with and (2) the token is actually a macro that resolves to the 'A' or 'W'
version depending on compiler settings.

If you have a better name suggestion I can correct it in the follow-up CL.

+
+ private:
+  OPENFILENAME openfilename_;
+  base::string16 initial_directory_buffer_;
+  wchar_t filename_buffer_[UNICODE_STRING_MAX_CHARS];
+
+  DISALLOW_COPY_AND_ASSIGN(OpenFileName);
+};
+
+}  // namespace win
+}  // namespace ui
+
+#endif  // UI_BASE_WIN_OPEN_FILE_NAME_WIN_H_