Я могу окончательно сказать, что нет решения, чтобы показать диалоговое окно «Сохранить как» в VBScript под версиями Windows, отличных от XP, не полагаясь на некоторые внешние зависимости, которые вы должны установить и зарегистрировать самостоятельно. Помимо очевидных помех, которые возникают в связи с простым развертыванием сценария с перетаскиванием и перетаскиванием, он также выявляет целый ряд других проблем, связанных с безопасностью и разрешениями, в частности, путем обхода UAC на машине клиента установить и зарегистрировать DLL зависимости.
Решения, которые были предложены до сих пор, полагаются либо на DLL-файл, который так просто входит в состав Windows XP, вызывая диалоговое окно «Сохранить как» на панели управления учетными записями пользователей Windows XP и/или устанавливая часть программного обеспечения только для того, чтобы он оставил после MSComDlg
DLL после его удаления, который затем можно использовать из VBScript. Ни одно из этих решений действительно не удовлетворяет вышеуказанным требованиям, и ни один из предоставленных ответов даже не рассматривал возможные препятствия безопасности, которые возникли бы с их предлагаемыми решениями, о чем я говорил выше.
И поскольку вы не можете звонить напрямую в Windows API (который всегда так удобно включает в себя именно такое диалоговое окно «Сохранить как») из VBScript (не только потому, что он будет представлять угрозу безопасности, но и из-за VBScript's свободный [недостаток?] ввода), что в значительной степени оставляет желающих сделать это на холоде. Кроме того, неспособность совершать вызовы API также исключает использование любых хаков, таких как вызов SetWindowText
, чтобы изменить заголовок диалогового окна Open, как это было предложено в вопросе.
Я понимаю, что это не тот ответ, который все желали. Это даже не тот ответ, который я хотел. Но, увы, это правильный ответ.
Это, как говорится, вот несколько возможных способы решения:
Если вы склоняетесь к принимая любой из уже предложенных ответов, вы уже решили ввести внешнюю зависимость от DLL-файл для развертывания VBScript. После того, как вы совершили этот скачок, зачем беспокоиться о «заимствовании» или иным образом захватывать DLL из какого-то другого источника? Просто сделай один раз сам. Тривиально обернуть собственные общие функции диалога, предоставляемые Windows API, в ActiveX DLL, используя Visual Basic 6, который затем можно вызвать вашим VBScript. Риски минимальны, поскольку почти любая современная версия Windows может ожидать, что уже установлена среда выполнения Visual Basic, и поскольку вы, вероятно, уже знаете VBScript, выбивание кода в VB 6 не должно быть очень сложным делом. Вы можете включить любые настраиваемые функции, которые вы хотите, и, самое главное, вы будете в полном контроле. Вам не придется беспокоиться о том, что деинсталляторы других приложений удаляют DLL, что требует ваш скрипт, вам не придется futz с установкой и удалением какого-то случайного, устаревшего приложения, и вам не придется просто скрестить пальцы и надеяться. Мы знаем, как программисты, это никогда не бывает хорошим вариантом.
И да, я рекомендую фактически обернуть общие функции диалога, открытые API Windows, вместо того, чтобы полагаться на общий диалог OCX (comdlg32.ocx
), предоставленный Visual Basic. У него есть доля проблем в Windows 7, и он не даст вам великолепных новых диалогов, которые предоставляют более поздние версии Windows. Отличная статья, объясняющая все, что вам нужно знать о Open и Save Common Dialog API и о том, как их использовать в VB 6, - available here on VBnet. Конечно, если вы действительно хотите изо всех сил, есть множество интересных вещей, которые вы можете делать с общими диалогами, все документально (с кодом!) here on 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? Опять же, есть все новые возможности, предлагаемые в VB.NET благодаря платформе .NET Framework, но для более достойного разработчика VB/VBScript не должно быть больше нескольких недель, чтобы начать чувствовать удобство написания приложений на VB.NET , Вероятно, у них не будет полного понимания .NET Framework, и они, конечно же, не будут разрабатывать хорошие объектно-ориентированные методы проектирования, но, по крайней мере, они будут двигаться в правильном направлении. Почти все, что вы можете сделать в VBScript (или даже VB 6), вы можете делать в VB.NET. И вообще, это требует еще меньше шума, чем раньше, благодаря огромной функциональности, открытой платформой .NET Framework. Недостатком, конечно же, является то, что ваше приложение теперь требует установки .NET Framework на компьютер пользователя, что не так повсеместно, как и во время работы VB 6 (хотя сейчас это гораздо более распространено, чем даже несколько лет тому назад).
Итак, я слышу, что вы говорите, что это были не обходные пути, которые вы надеялись услышать? Да, и я. Я не тот парень, который говорит, что люди бросают все и изучают новый язык. Если VBScript продолжает работать на вас, перейдите к нему. Но если вы находитесь в тот момент, когда вы начинаете напрягаться по своим ограничениям, вероятно, пора совершить прыжок.
"UserAccounts.CommonDialog" работает только на Windows XP. Он не будет работать под Windows Vista или более поздней версией. Это уместно для вас? – 2010-12-08 10:00:09
Ну ... в данный момент нет, но надежное решение, вероятно, будет лучше. Спасибо за этот намек. – JayK 2010-12-08 10:05:27
+1 за отличный вопрос. Чем больше я использую Google, тем больше похоже, что на самом деле это не универсальное решение. Материал там будет работать только в Windows XP (не ранее или более поздних версиях) и/или имеет внешние зависимости. Некоторые примеры даже открывают Internet Explorer и используют его диалоговое окно, пока он скрыт, что кажется мне очень плохой идеей. Также нет способа вызвать собственные API Win32 из VBScript, поэтому я почти готов заключить, что решения нет. Является ли внешняя зависимость (например, DLL-файл, который вы должны включить в сценарий), или с помощью скомпилированного языка, такого как VB 6, опция? – 2010-12-08 10:30:21