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