Tim*_*ple 6 .net webbrowser-control winforms
首先是几个定义,以保持清晰.
用户:使用该软件的现场人员
客户:为其用户支付定制版软件的公司.
我们目前有一些应用程序需要根据用户所属的客户端对用户界面进行重大更改.我们目前为每个客户端都有一个单独的构建,但随着客户端数量的增加,管理所有这些单独版本变得更加困难.
我的目标是切换到一个可以根据登录的人动态定制的通用客户端.由于我们的软件无论如何都需要互联网连接(广泛使用web服务)我正在考虑在.NET中使用WebBrowser控件并允许它与计算机上所需的硬件进行交互(通过ObjectForScripting).
然后整个用户界面用HTML/JavaScript编写并存储在服务器上,使得新用户界面的分发和维护变得微不足道.通用客户端不过是一个自定义Web浏览器,它知道如何与我们的硬件设备通信,并且可以通过javascript告知它.
我看到这种方法有很多优点,而且没有太多缺点.我错过了什么？我为什么不走这个方向？
有一些商业应用程序成功使用这种方法.以下是需要牢记的一些注意事项.这些不应该阻止你尝试这种方法.但是,要问自己一个关键问题是应用程序是否可以是本机Web应用程序.
Web浏览器控件"吃标签".您可以使用Tab键将输入焦点从托管应用程序移动到浏览器控件中,但是您无法通过它标记出来(除非您明确地编写代码)
HTML/Javascript应用程序是单线程的.如果您需要任何后台处理,则可能需要将该任务委派给托管应用程序.
如果Web浏览器控件中出现错误情况,则将它们视为脚本错误,并包含在控件内.收容是件好事.但您可能甚至没有意识到构建/调试时出现错误情况.
如果没有网络连接,用户可以看到浏览器的故障页面.你不能先抢占它并展示自己的信息.
根据您的应用程序及其实现方式,导航可能看起来比桌面应用程序中常见的更缓慢.特别是页面重新加载.小心使用异步AJAX可以帮助减轻部分或全部.
您的用户将知道他们正在使用网页.单独的UI设计无法隐藏这一事实.响应性和偶尔的失败将揭示这一事实.这对您来说可能是也可能不是问题.
您的应用程序必须支持多个浏览器版本..NET Web浏览器控件是用户计算机上Internet Explorer实现的包装器.这将是IE6,7,8等,具体取决于那里安装的内容.