WebBrowser управляют как Пользовательский интерфейс
MSDN, кажется, указывает, что броски Cxxx для определенных типов могут улучшить производительность в.NET VB, потому что они преобразовываются во встроенный код. По некоторым причинам это также предлагает DirectCast в противоположность CType в определенных случаях (состояния документации, которые это - когда существуют отношения наследования; я полагаю, что это означает, что исправность броска проверяется во время компиляции, и оптимизация может быть применена, тогда как CType всегда использует время выполнения VB.)
то, Когда я пишу код.NET VB, что я использую, зависит от того, что я делаю. Если это - код прототипа, я собираюсь выбросить, я использую то, что я, оказывается, ввожу. Если это - код, я серьезно отношусь к, я пытаюсь использовать бросок Cxxx. Если Вы не существуете, я использую DirectCast, если у меня есть разумная вера, что существуют отношения наследования. Если это - ситуация, где я понятия не имею, должен ли бросок успешно выполниться (ввод данных пользователем-> целые числа, например), то я использую TryCast, чтобы сделать что-то более дружественное, чем бросок исключение в пользователе.
Одна вещь, которую я не могу встряхнуть, я склонен использовать ToString вместо CStr, но предположительно Cstr быстрее.
6 ответов
Есть несколько коммерческих приложений, которые успешно используют этот подход. Ниже приведены некоторые соображения, о которых следует помнить. В любом случае это не должно помешать вам попробовать подход. Однако ключевой вопрос, который стоит задать себе, заключается в том, может ли приложение быть собственным веб-приложением.
Элемент управления веб-браузера «ест вкладки». Вы можете использовать клавишу табуляции, чтобы переместить фокус ввода в элемент управления браузера из хост-приложения, но вы не можете выйти из него табуляцией (если вы не кодируете это явно)
Приложения HTML / Javascript являются однопоточными. Если вам нужна какая-либо фоновая обработка, вам может потребоваться делегировать эту задачу приложению хостинга.
Если условия ошибки возникают внутри элемента управления веб-браузера, они обрабатываются как ошибки сценария и содержатся внутри элемента управления. Сдерживание - это хорошо. Но вы можете даже не осознавать, что во время сборки / отладки возникла ошибка.
Если нет подключения к сети, пользователи могут увидеть страницу сбоя браузера. Вы не можете вытеснить это и показать собственное сообщение.
В зависимости от вашего приложения и того, как оно реализовано, навигация может показаться более медленной, чем это обычно бывает в настольных приложениях. В частности, перезагружается страница. Осторожное использование асинхронного AJAX может помочь частично или полностью облегчить это.
Ваши пользователи будут знать, что они работают с веб-страницей. Сам по себе UI-дизайн не сможет скрыть этот факт. Отзывчивость и случайные отказы раскроют этот факт. Это может быть для вас проблемой, а может и не быть.
Ваше приложение должно поддерживать несколько версий браузера. Файл. Элемент управления веб-браузера .NET представляет собой оболочку для реализации Internet Explorer на компьютере пользователя. Это будет IE6, 7, 8 и т. Д. В зависимости от того, что там установлено.
Разве WPF не даст вам преимуществ легко снимать скин для разных пользователей, сохраняя при этом богатые преимущества пользовательского интерфейса?
Это зависит от типа приложения, но я не понимаю, почему это не могло работать. Возможные недостатки: вам нужно работать в HTML и JavaScript, компонент WebBrowser зависит от установленной версии Internet Explorer (не всегда один и тот же), пользовательский интерфейс на самом деле не является родным и, вероятно, будет похож на веб-приложение (не обязательно быть недостатком). Если я прав, я думаю, что пользовательский интерфейс Microsoft Money полностью основан на элементе управления WebBrowser.
Я бы не рекомендовал использовать элемент управления WebBrowser, если вам нужно реализовать какие-либо сложные функции. Недостатки:
Его поведение зависит от установленной версии IE и настроек IE, но не идентично «настоящему» IE. Я видел несколько случаев, когда функциональность JS работала в автономном IE, но не работала в элементе управления WebBrowser без какой-либо очевидной причины (и, следовательно, без возможности исправить это).
Трудно настроить пользовательский интерфейс (изменить контекстное меню, создать несколько сложных обработчиков событий), поскольку элемент управления не раскрывает большую часть самого себя. Таким образом, может быть неоправданно сложно заставить его взаимодействовать с envinronment так, как вам нужно.
Вы можете рассмотреть возможность использования полностью веб-решения, работающего в автономном браузере - по крайней мере, вы гораздо менее вероятно чтобы найти там необычный баг. Для взаимодействия с оборудованием можно использовать апплет или элемент управления ActiveX.
Другой вариант - разработать тонкий клиент как приложение Windows, которое каким-то образом настраивалось бы в зависимости от пользователя. Если вам все еще нужно встроить браузер, вы можете использовать Gecko (движок Mozilla) или WebKit (движок Chrome) - у меня нет практического опыта работы с ними, но, вероятно, у них больше согласованности между встроенными и автономными версиями. .
Если вы не теряете важные функции пользовательского интерфейса при переходе на веб-интерфейс, я не понимаю, почему это не лучшее решение.
На самом деле, похоже, отличное решение. Однако в голову приходит одна вещь:
Почему бы просто не перейти на полноценное веб-приложение? Есть ли определенные вещи, которые вы можете делать только на стороне клиента вне браузера? Потому что в противном случае вы, вероятно, значительно упростите свои сценарии развертывания, просто сделав все это веб-приложением.