Я могу однозначно сказать, что не существует решения для отображения диалогового окна «Сохранить как» из VBScript в версиях Windows, отличных от XP, не полагаясь на некоторые внешние зависимости, которые необходимо установить и зарегистрировать самостоятельно. Помимо очевидное вмешательство, которое это вызывает в отношении простого развертывания вашего сценария путем перетаскивания, оно также поднимает целый ряд других проблем, связанных с безопасностью и разрешениями, в частности, в обход UAC на компьютере клиента для установки и регистрации DLL зависимостей.
Решения, которые были предложены до сих пор, основаны либо на DLL-файле, который так же включается в Windows XP, вызывая диалоговое окно «Сохранить как» из панели управления учетными записями пользователей Windows XP и / или устанавливая часть программного обеспечения. только для того, чтобы оставить после себя MSComDlg DLL после ее удаления, которую затем можно использовать из VBScript. Ни одно из этих решений действительно не удовлетворяет вышеуказанным требованиям, и ни один из предоставленных ответов даже не рассматривал возможные препятствия безопасности, которые могли бы возникнуть с их предлагаемыми решениями, как я упоминал выше.
И так как вы не можете совершать вызовы непосредственно в Windows API (который очень удобно включает в себя только такой диалог Сохранить как) из VBScript (не только потому, что это создает угрозу безопасности, но также из-за потери VBScript [нехватка?] печатать), это в значительной степени оставляет любого желающего сделать это на морозе. Кроме того, невозможность выполнения вызовов API также исключает использование любых хаков, таких как вызов SetWindowText, для изменения заголовка диалога Open, как предлагается в вопросе.
Я понимаю, что это не тот ответ, которого все хотели. Это даже не тот ответ, который я хотел получить. Но, увы, это правильный ответ.
Как говорится, вот несколько возможных обходных путей:
Если вы склонны принять какой-либо из уже предложенных ответов, вы уже решили ввести внешнюю зависимость от DLL-файла в ваше развертывание VBScript. После того, как вы совершили этот скачок, зачем беспокоиться о «заимствовании» или хищении DLL из какого-либо другого источника? Просто сделай однажды себя. Это тривиально, чтобы обернуть встроенные общие функции диалога, предоставляемые API Windows, в DLL ActiveX с помощью Visual Basic 6, которая затем может быть вызвана вашим VBScript. Риски минимальны, поскольку можно ожидать, что практически в любой современной версии Windows уже установлена среда выполнения Visual Basic, и, поскольку вы, вероятно, уже знаете VBScript, создание некоторого кода в VB 6 не должно быть очень трудным делом. Вы можете включить любые пользовательские функции, которые вы хотите, и, что наиболее важно, вы будете под полным контролем. Вам не придется беспокоиться об удалении других приложений, удаляющих DLL, которая требуется вашему сценарию, вам не придется возиться с установкой и удалением какого-либо случайного устаревшего приложения, и вам не придется просто скрестить пальцы и надеяться. Мы, программисты, знаем, что это хороший вариант.
И да, я рекомендую фактически обернуть общие диалоговые функции, предоставляемые Windows API, а не полагаться на общий диалог OCX (comdlg32.ocx), предоставляемый Visual Basic. У него есть свои проблемы в Windows 7, и он не даст вам великолепных новых диалогов, которые теперь предоставляют более поздние версии Windows. Отличная статья, объясняющая все, что вам нужно знать об API Open and Save Common Dialog и о том, как их использовать в VB 6, доступна здесь, в VBnet . Конечно, если вы действительно хотите сделать все возможное, есть множество интересных вещей, которые вы можете сделать с помощью обычных диалогов, все они документированы (с кодом!) здесь, на VB Accelerator .
Но теперь, когда я убедил вас всех написать DLL ActiveX в VB 6, которая включает в себя функциональность общего диалога для использования в вашем VBScript, я должен задать вопрос: зачем останавливаться на достигнутом? После того как вы сделали прыжок для написания некоторого кода в VB 6, почему бы не переместить все вашего кода в VB 6? Конечно, это «мертвый» язык и все такое, но VBScript тоже не слишком активен. Как я уже упоминал ранее, разница в синтаксисе практически равна нулю, а кривая обучения для разработчика VBScript примерно такая незначительная, как можно было ожидать. Кроме того, вы получаете все преимущества полной IDE, статической типизации, (немного) лучшей обработки ошибок, бла-бла-бла. О да, и возможность делать прямые вызовы функций Windows API. Единственным реальным преимуществом VBScript является его повсеместное распространение, но прошло уже лет , поскольку вы могли найти компьютер без установленной среды выполнения VB. Не говоря уже о том, что если вы пишете приложение, для которого требуются общие диалоговые окна, вы, вероятно, вступаете в диалог со своими пользователями: возможность создания форм с полным VB может начать пригодиться в этот момент. , Но, пожалуй, самое большое и самое важное преимущество выбора этого пути состоит в том, что вы избавляете от необходимости регистрировать (или включать) внешнюю «спутниковую» DLL - простое приложение VB 6 будет работать только с EXE на любом компьютере, на котором есть Установлено время выполнения VB, которое включено как минимум через Windows 7.
И, наконец, в случае, если вы все взволнованы переходом от скромного VBScript к полнофункциональному VB 6, я чувствую себя обязанным добавить еще один гаечный ключ в уравнение: почему бы не двигаться полностью до языка, как VB.NET? Опять же, благодаря .NET Framework, в VB.NET предлагаются всевозможные новые функции, но для того, чтобы приличный разработчик VB / VBScript почувствовал себя комфортно при написании приложений на VB.NET, не потребуется более нескольких недель. , Вероятно, у них не будет полного понимания .NET Framework, и они, конечно, не разработают хорошие методы объектно-ориентированного проектирования, но, по крайней мере, они будут двигаться в правильном направлении. Почти все, что вы можете сделать в VBScript (или даже VB 6), вы можете сделать в VB.NET. И вообще, это требует еще меньше суеты, чем раньше, благодаря огромной функциональности .NET Framework. Недостатком, конечно же, является то, что вашему приложению теперь требуется установить .NET Framework на компьютер пользователя, что не так широко распространено, как во время выполнения VB 6 (хотя сейчас это происходит гораздо чаще, чем даже через несколько лет). назад).
Итак, я слышал, как вы говорили, что это не те обходные пути, которые вы надеялись услышать? Да, я тоже. Я не тот парень, который говорит людям бросить все и выучить новый язык. Если VBScript продолжает работать для вас, перейдите на него . Но если вы находитесь в той точке, когда вы начинаете напрягаться из-за ее ограничений, возможно, пришло время совершить скачок.