Access有哪些控件直接支持http协议?
已有 2127 次阅读2015-11-25 18:22
|个人分类:access入门
在网络时代的今天,access其实会越来越成为一个富客户端(如果从office的安装率上来看)。
让人沮丧的是,access对web的支持非常迟缓。而web数据库对于普通大众来说,是遥远而不可及的。
sharepoint server对于普通人来说,根本就是用不起(也没那个时间和精力来用好它)。
一般来讲,access+SQL server是一种黄金搭配。这是典型的c/s结构。不过,估计也有好多人,对这种搭配非常苦恼。因为它确实也有一些不便的地方,比如office文档的管理,图片的管理,以及其它形形色色的需要从各个地方收集数据(这种收集需要自动化)。
access有哪些控件直接支持http协议呢?目前为止,一个都没有!当然我对access不熟也有关。不过,目前暂时没有发现。
一:image控件不支持http协议。如果要显示网络上的图片,应该用web控件代替image
如果你在窗体中这样写:me!image0.picture="http://127.0.0.1/picture/11.jpg"。那么将发生错误。图片无法载入image控件中。
这时,应该用me!webbrowser1.datasource="http://127.0.0.1/picture/11.jpg"来代替。
但webbrowser用来显示图片,也是有明显的缺点:
(1)webbrowser只能用于单窗体,无法用于连续窗体,也无法用于数据表视图
(2)图片如果要做到精确控制(如自动拉伸,平铺、缩略图,百叶窗展示等特效)则需要使用html,通过html来精确控制图片的特效。
应该说webbrowser是access通向网络的一个很重要的通道。
二、ADO主要的对象,都默认支持http协议。
这算是一个不错的消息。因为recordset,record,stream都支持http协议(也支持ftp协议),这无形中会为access在使用网络方面,带来很大的便利。
三、xmlhttp控件
在b/s模式中,xmlhttp几乎是不可缺少的主角。同样,在access中也可以使用xmlhttp。这几乎也是access提交数据的唯一途径了。而且xmlhttp是异步的,多少能弥补点vba单线程的缺憾(vba的单线程,注定它难以适应web时代)
四、winhttp5.1 控件
这个东西同样适用于access。只不过它更强大,同时也更复杂。它是网抓的利器
五、owssup.dll
access的模板是如何从微软网站上下载下来的。就是利用owssup.dll这个工具,这是一个上传下载的工具。只不过它限制得比较厉害,所以变得很不好利用。不过,在个别的时候还是可以用得上。
六、hyperlink对象?
我对hyperlink对象,印象不深。但hyperlink.follow支持get,我们好理解,但支持post方法,变得有点不可思议了。怎么post?
这其实是一个活生生的get和post请求的构造器呀,但却没有告诉我们应该怎么用?特别是post方法。如果有人用过,望不吝告知,谢谢
/**********************************************************************/
说明1:以我菜鸟级的理解,在access的窗体中千万不要直接使用web控件,而是应该通过activeX控件,引用webbrowser。至于个中原因,我只能说微软提供的web控件有点邪门,在细节的地方会把你往死里整,而且功能会很大缩水。
引用webbrowser后,access依然会认为你使用web控件,这是没办法改变的。假设你把这个web控件名称改成wb0,那么在窗体的代码:
dim ctlWeb as webbrowser
set ctlWeb =wb0.object
这样子,ctlWeb就是一个完整的webbrowser。
说明2:webbrowser在默认的情况,会使用ie7的模式打开html网页。如果你想要使用html5和css3,则要万分注意兼容性了。百度一下,关于html文档兼容性讨论的内容非常多,甚至如何hack ie的讨论也是长篇累牍的。有关这方面,要多留意。
问题记录点1:今天想要在access窗体中subClass这个webbrowser并不成功。主要是想解决webbrowser打开网页后,去屏掉右键菜单,用自定义菜单替换掉。可惜并不成功,原因可能是access的form并没有popupMenu这个方法,而只有一个shortcutMenu属性
问题记录点2:access的Web化正常来说有两种方式:
(1)是access界面库的web化;
(2)是access作为富客户端,而逻辑处理在服务器端,在这一点上access依然有很大的存在价值。不过我现在对vba这个脚本语言产生很大的怀疑。因为同样作为脚本语言,不管是lua,javascript,还是python,都是突飞猛进,但vba自从1997年到现在,都没有变过(有变的也只是增加longlong和longptr这个类型)其它的一点变化都没。vba不管是编辑器,调试工具,还是语言本身,都远远落后这些脚本语言,看起来被取消,估计是指日可待。目前它只是看上去依然可用,也仅此而已。
问题记录点3:access的界面Web化。
有几个关键点需要突破:(1)就是html文件编译成dll。比较幸运的webbrowser依然支持res协议,这个我在win8.1+office2010和win10+office2016中都亲测可用。winxp+office2003也是可用的。换句话说这没有任何限制。所以问题变成,如何将众多的html文件变成一个dll文件。
这个问题是非常重要的,因为不管是选择mshtml作为解析引擎,还是选择webkit或者是更适用当界面库的htmlayout,都首先要解决资源文件问题。在access中还是用mshtml这个比较亲近一些,大家也比较熟悉。
(2)#include的问题。比较幸运的在webbrowser中#include还是可以被解决。通过document的文档行为,在一个html文件中可以加载另外的html文件
并且把它们包含成一个html文件。这样可以解决页眉,页脚这种固定格式的东西,也可以解决iframe这样类似子窗体的页面问题。
(3)web页面的数据交互:数据交互,我目前想到就是两种方式:<1>自循环方式。所谓的自循环方式,就是让access程序本身既是server端,也是web端,通过端口比如80端口,进行数据交互。这种方式看起来有点绕,但它非常符合,现在绝大多数js框架的数据交互方式。不需要更新任何js代码,都可以直接用。省时省力,但就是使用方式有点饶。虽然近在咫尺,却要绕地球一圈。
<2>硬编码方式。这是不少人用过,但却感觉挫折感很强的方式。这种方式一般首先就是让webbrowser无法提交网络数据,通过捕获html的tag事件来进行数据交互。这里面也分为两种方式,一种就是 private withevents as mshtml。然后开始……。另一种方式,是使用windows.external。很奇怪的是windows.external居然无法直接执行vba函数。虽然在vb6中可以通过olelib来解决,但在access中,这却是行不通的,因为access本身没有任何编译功能。除非是用vb6进行包装。
(4)数据绑定问题:
数据绑定这个问题,实质上和页面交互问题是一样的,ie其实不缺数据绑定功能。可以说早期的微软在web桌面化也下过很大的功夫,可惜都失败了。这些失败反而成为ie极大的包袱。ie的数据绑定一般有三种方式。其中有一种方式,就是可以直接绑定recordset。不过现在的js框架,基本上都是通过json来操作数据。所以这种方式在access的web化过程中,是一个需要反复琢磨值不值用的问题