javascript与Windows Presentation Foundation交互通讯（js与WPF通讯）
我的图书馆
javascript与Windows Presentation Foundation交互通讯（js与WPF通讯）
& & 　　　　wpf设置
　　1.给主程序类添加标签特性： [System.Visible(true)]
　　如： [System.Visible(true)]
　　public partial class MainWindow : Window
　　2.定义webbrowser导向网址：
　　webMain.Navigate(@"http://10.0.0.86:81");
　　webMain.Navigate(new Uri(@"E:\visual studio 2012\ShineHATMV1.0\WpfApp\testInterface.html", UriKind.RelativeOrAbsolute));
　　3.从wpf推送的页面函数及参数
　　webMain.Dispatcher.Invoke(new Action(() =& { webMain.ObjectForScripting = webMain.InvokeScript("funName",new object[]{"paras"}); }));
　　方法名称：funName，参数：paras 页面中必须有同名同类型的参数;
　　4.从页面js调用wpf方法 页面js调用
　　window.external.CallBll("test");
　　wpf中： 需要提前定义好一个 接受类
　　//前台js调用后台js方法
　　[System.Visible(true)]
　　public class JSCallBack{}
　　在初始化一下 这个类
　　JSCallBack jscall = new JSCallBack(this);
　　webMain.ObjectForScripting =
　　在类中定义好接收方法
　　//前台调用方法
　　public string CallBll(string type){}
　　5.注意 wpf 需在 webbrowser的LoadCompleted 事件执行之后才能使用 js 与 wpf 的相互之间的调用，winform没有验证
　　详细代码：
namespace WpfApp
/// &summary&
/// MainWindow.xaml 的交互逻辑
/// &/summary&
[System.Visible(true)]
public partial class MainWindow : Window
public MainWindow()
InitializeComponent();
//webMain.Navigate(@"http://10.0.0.86:81");
webMain.Navigate(new Uri(@"E:\visual studio 2012\ShineHATMV1.0\WpfApp\testInterface.html", UriKind.RelativeOrAbsolute));
private void btrInCard_Click(object sender, RoutedEventArgs e)
CallBackEvent("bank");
private void Button_Click_1(object sender, RoutedEventArgs e)
JSCallBack jscall = new JSCallBack(this);
webMain.ObjectForScripting =
//向前台 推送方法
void CallBackEvent(string type)
//function callbackEvent(isok, value, status, code, msg, fun)
//isok:0 失败 1 成功
//type:bankPwd
//value：bankNo:,name:张三,ablance:500
//msg:提示信息
switch (type)
case "test":
webMain.Dispatcher.Invoke(new Action(() =& { webMain.ObjectForScripting = this; webMain.InvokeScript("test"); }));
case "bank":
webMain.Dispatcher.Invoke(new Action(() =& { webMain.ObjectForScripting = this; webMain.InvokeScript("callbackEvent", new object[] { <span style="color: #, "bankPwd", "bankNo:6135513$$bankName:农业银行", "" }); }));
//前台js调用后台js方法
[System.Visible(true)]
public class JSCallBack
MainWindow mainW
public JSCallBack(MainWindow main)
mainWindow =
//前台调用方法
public string CallBll(string type, int isOk, string paras)
switch (type)
case "inputBankPwd":
case "bank":
return "test";
　　html：
&!DOCTYPE html&
&html lang="en" xmlns="http://www.w3.org/1999/xhtml"&
&meta charset="utf-8" /&
&title&&/title&
&script type="text/javascript"&
//function callbackEvent(isok, type,value, msg)
//isok:0 失败 1 成功
//type:bankPwd
//value：bankNo:,name:张三,ablance:500
//msg:提示信息
function callbackEvent(isok, type, value, msg) {
document.getElementById("test").innerHTML = isok + "|" + type + "|" + value + "|" +
alert(isok + "|" + type + "|" + value + "|" + msg);
function test() {
document.getElementById("test").innerHTML = "test";
function callbll() {
//window.external.CallBll(type, isok, paras);
//type:inputBankPwd
//isok:0 失败 1 成功
//paras:参数：bankNo:,name:张三,ablance:500
var ss = window.external.CallBll("inputBankPwd", 1, "");
alert(ss);
&div id="test" onclick="callbll();"&uuuu&/div&
　　如果出现以下错误
　　1.如果直接在 初始化中写入 webMain.ObjectForScripting =
　　则会出现如下错误：“执行了 QueryInterface 调用，请求提供 COM 可见的托管类“WpfApp.MainWindow”的默认 IDispatch 接口。不过，由于该类没有显式默认接口，并且是从非 COM 可见的类“System.Windows.Window”派生的，QueryInterface 调用将失败。这样做的目的是避免非 COM 可见的基类受 COM 版本规则的约束。”
　　2.如果在初始化时候直接从后台向页面执行方法，没有加载完毕webbrowser的LoadCompleted事件，会有如下，错误
　　“对类型“WpfApp.MainWindow”的构造函数执行符合指定的绑定约束的调用时引发了异常。”，行号为“3”，行位置为“9”。
　　若要避免以上两种错误，只要在加载完毕webbrowser的LoadCompleted事件之后执行交互即可，也就是说尽量不要在初始化的时候，进行交互，如要十分需要，只要使用timer，异步线程，就可以了，因为在去执行其他线程的时候 主线程已经执行完毕初始化，LoadComplated事件也已经被执行完毕。
　　本文来自yylp521的博客，原文地址：/yylp521/archive//wpf与js.html
TA的推荐TA的最新馆藏就算在微软，【结合公司目前的工作内容进行提高】这个前提都不一定能成立，你就别想了。好好在家里写自己的代码。
就算在微软，【结合公司目前的工作内容进行提高】这个前提都不一定能成立，你就别想了。好好在家里写自己的代码。
&p&不匿名反对轮子 &a class=&member_mention& href=&///people/ecc0ec035f& data-hash=&ecc0ec035f& data-hovercard=&p$b$ecc0ec035f&&@vczh&/a& ，这个问题他给的答案是没有什么卵用的，不能用于大规模的wpf开发。他提供的使用方式停留在《XXX从入门到精通》这种书介绍的使用方式上。&/p&&p&1.首先你要学会在项目里使用相对路径，如下图，在GUI主工程目录里创建等资源目录Resource，再创建相应的子目录。提示音，图片什么的可以放这个目录里。&/p&&img src=&/v2-409f9b0b9a67bc3f77ccc4_b.png& data-rawwidth=&1522& data-rawheight=&756& class=&origin_image zh-lightbox-thumb& width=&1522& data-original=&/v2-409f9b0b9a67bc3f77ccc4_r.png&&&p&2.使用的时候，和我上面的图一样，使用相对路径。就可以解决你说的所有问题。&/p&&br&&p&以上的管理方式，适用于软件的工业化生产，无论你的应用是有几十个还是几百个窗体，都没有问题，整体针对资源的管理都是很清晰明了的，成员配合开发也不会有问题。你要写个toy，搞几个窗体玩玩，当我没说。&/p&&br&&p&我的观点是在理论中实践，在实践中探索有利于我们生产的改进。不做学院派。什么是学院派？数据库关系理论说设计要遵守三范式，学院派就会把我们的数据表关系拉的像蜘蛛网一样。假设当你的应用是单库数百张张表，有着很复杂的业务。学院派的生产产物有 很高的可能性是不合格的，说到这里也不用我再多解释了吧~&/p&&br&&p&新手上路，需要老司机告诉他们的难道不是莫打滚爬出来的经验？&/p&
不匿名反对轮子
，这个问题他给的答案是没有什么卵用的，不能用于大规模的wpf开发。他提供的使用方式停留在《XXX从入门到精通》这种书介绍的使用方式上。1.首先你要学会在项目里使用相对路径，如下图，在GUI主工程目录里创建等资源目录Resource，再创…
因为用C++写GUI是我这种有情怀的人才会做的事情。
因为用C++写GUI是我这种有情怀的人才会做的事情。
恰恰相反，不调用DirectX的屏幕绘制才是浪费。&br&&br&用DirectX绘制速度更快，可以节约数倍的时间。通常，DirectX绘图可以快3-10倍。DirectX的出现，就是为了解决Windows GDI绘图太慢的问题，而采用了直接操作显存的方式。传统GDI是先在内存绘图然后再传送到显存显示的，传送和复制都要消耗时间。何况显存本身比内存更快，所以直接写显存的DirectX更高效。&br&&br&至于普通程序采用低速的GDI/GDI+，完全是是早期架构的延续以及开发方便，而并非为了性能。早期显卡性能低下，Windows也没有预置DirectX方案。后来由于3D游戏和高清视频的推进，显卡硬件提升了数百倍（远远高于CPU的提速），DirectX的优势才愈发凸显。但直接调用DirectX非常繁琐，WPF封装了这一过程，用户无需关心后台就可以放心使用了。
恰恰相反，不调用DirectX的屏幕绘制才是浪费。 用DirectX绘制速度更快，可以节约数倍的时间。通常，DirectX绘图可以快3-10倍。DirectX的出现，就是为了解决Windows GDI绘图太慢的问题，而采用了直接操作显存的方式。传统GDI是先在内存绘图然后再传送到显存…
后来WPF的XAML重新实现了一次变成了UWP，UWP的JavaScript部分在github上开源了叫winjs，可以跑在浏览器里，功能几乎一致。对于那些喜欢用HTML写UI的人，基本上就等于跨平台了。
后来WPF的XAML重新实现了一次变成了UWP，UWP的JavaScript部分在github上开源了叫winjs，可以跑在浏览器里，功能几乎一致。对于那些喜欢用HTML写UI的人，基本上就等于跨平台了。
Windows的未来，无论是桌面、Metro（包括Windows Phone），都会越来越倚重WPF——包括狭义上的.NET WPF、Silverlight和适用于Metro的Xaml技术。虽然微软在Metro上引入了HTML5，但相比来说WPF依然是主流。&br&至于跨平台，Mono已经明确地表示暂无支持WPF的计划，因此短期内（几年内）都无法在其他平台上使用WPF。Silverlight已经有其他平台上的开源版本，但据我所知都不算理想。&br&更广义上来说，WPF提供了一种非常先进的界面抽象方式，我相信这种思想会极大地影响到未来的界面框架，从这一点上来说，WPF前途无量。
Windows的未来，无论是桌面、Metro（包括Windows Phone），都会越来越倚重WPF——包括狭义上的.NET WPF、Silverlight和适用于Metro的Xaml技术。虽然微软在Metro上引入了HTML5，但相比来说WPF依然是主流。 至于跨平台，Mono已经明确地表示暂无支持WPF的计划…
轻量，灵活。不要动不动就一套框架，就一个简单的能让游戏引擎调用的UI渲染和输入就行了。需要能接入引擎本身的渲染接口和输入接口，而不是直接跟系统打交道。（甚至字体渲染和矩形管理都交给引擎）&br&&br&MyGUI和CEGUI都是不错的选择。
轻量，灵活。不要动不动就一套框架，就一个简单的能让游戏引擎调用的UI渲染和输入就行了。需要能接入引擎本身的渲染接口和输入接口，而不是直接跟系统打交道。（甚至字体渲染和矩形管理都交给引擎） MyGUI和CEGUI都是不错的选择。
用C++重新实现了一遍，API没改，C#还能用，使用C++、Javascript和Objective C来开发也由Visual Studio直接支持了，现在改名叫UAP了。
用C++重新实现了一遍，API没改，C#还能用，使用C++、Javascript和Objective C来开发也由Visual Studio直接支持了，现在改名叫UAP了。
微软专注赶跑不愿学习的程序员五十年
微软专注赶跑不愿学习的程序员五十年
&p&MFC都还在更新，你跟我说怕WPF被瞪？再说了，现在不支持UWP的所有版本已经官方不支持了，以后他们就会变成一样的东西（逃&/p&&p&至于WPF和.net的稳定与速度，你天天用Visual Studio，没体验出来吗？&/p&
MFC都还在更新，你跟我说怕WPF被瞪？再说了，现在不支持UWP的所有版本已经官方不支持了，以后他们就会变成一样的东西（逃至于WPF和.net的稳定与速度，你天天用Visual Studio，没体验出来吗？
面向对象从一开始就是为了解决GUI才被发明出来的，后来被修改之后扩展到了很多其他领域里面。所以凡是一个灵活的GUI库，必然是充斥着大量的设计模式的（不管作者是不是有意这么做）。
面向对象从一开始就是为了解决GUI才被发明出来的，后来被修改之后扩展到了很多其他领域里面。所以凡是一个灵活的GUI库，必然是充斥着大量的设计模式的（不管作者是不是有意这么做）。
需要注意的是，XP已经被淘汰了，别支持了。
需要注意的是，XP已经被淘汰了，别支持了。
DirectX里面的DirectWrite性能多高啊，而且各种图文混排和多语言支持都是Windows上所有solution里面最好的，Chrome在Windows 7和以上也放弃了自己在别的平台的渲染引擎改用DirectWrite，不用才是浪费。
DirectX里面的DirectWrite性能多高啊，而且各种图文混排和多语言支持都是Windows上所有solution里面最好的，Chrome在Windows 7和以上也放弃了自己在别的平台的渲染引擎改用DirectWrite，不用才是浪费。
觉得收入上不去 就要给自己做技术投资
不是说找到了下家才能转方向，没有用人单位会愿意培训一个理应是熟手的三年经验工作者。&br&&br&很简单，找到感兴趣的方向 并且自己动手实践一些，比如&a href=&///?target=http%3A//asp.net& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&asp.net&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& /azure 方向
自己拿出几千块钱搞个账号配置运行练习并不是会导致你找不到女朋友或者因此分手那么严重。&br&&br&当然如果你觉得WPF XAML 方向你很喜欢，那么接触UWP /Xamarin Forms 开发也是很棒的，因为你可以不限与桌面端发挥你的经验累积。&br&&br&最怕的是你在投资前犹豫。 你投入到技术的主要是你的时间
你犹豫的时间不但不会让你的技术增值 还会影响你的玩乐 让你不幸福。 &br&&br&是的浪费时间会找不到女朋友或者让女朋友分手
觉得收入上不去 就要给自己做技术投资 不是说找到了下家才能转方向，没有用人单位会愿意培训一个理应是熟手的三年经验工作者。 很简单，找到感兴趣的方向 并且自己动手实践一些，比如 /azure 方向 自己拿出几千块钱搞个账号配置运行练…
WPF，你能找到比他更好的开发工具么？以前是有Delphi，C++ Builder，现在都收费了，很贵的。&br&&br&什么QT之类的就不要拿来说了，同样的功能，Qt还在那磨磨蹭蹭不知道该死的bug出在那里，还在复杂的界面逻辑纠结，还在那考虑如何提高响应速度，还在想着怎么发布安装包，怎么给新电脑部署开发环境。WPF三下两下搞定了，结构逻辑清清楚楚，C#还优美好用，现在Visual studio已经免费了，谁都能用，配环境的时间等于零，而且VS2013这个IDE你去试试，爽死人不偿命的，如果以后我开公司，肯定统统C#,WPF，这个开发效率的提升带来的是纯粹的大幅成本下降。&br&&br&我很久以前用Delphi和C++ Builder，后来用Qt，现在用WPF和C#，效率太高了，真的是得心应手，那么复杂的功能能那么快的实现，我感谢微软。&br&&br&不过跟找工作无关，要说找工作，这些统统都得会，还有MFC也要会哦&br&&br&汪汪汪
WPF，你能找到比他更好的开发工具么？以前是有Delphi，C++ Builder，现在都收费了，很贵的。 什么QT之类的就不要拿来说了，同样的功能，Qt还在那磨磨蹭蹭不知道该死的bug出在那里，还在复杂的界面逻辑纠结，还在那考虑如何提高响应速度，还在想着怎么发布安…
以上几个答案都有点站着说话不腰痛。
&br&&br&微软干掉某项技术已经不是一次两次了，所以一有新东西推出，大家就有狼来了的感觉。
&br&&br&对于个人，无所谓，大不了花几个月重学一门新技术。但是对于公司，失去的就不仅仅是重新学习的成本。
&br&&br&例如，公司花了几个月做了一个基于Silverlight的项目，突然听说微软不更新Silverlight了，该怎么办？
&br&&br&继续做下去，意味着未来可能不能及时得到来自微软维护保障，意味着项目依赖的控件库可能得不到功能上的增强，意味着将来从事Silverlight的人才越来越难招，意味着使用Silverlight会被甲方认为过时的技术而无法和竞争对手PK。&br&重新换一种开发技术，意味着需要重新建立开发团队，意味着代码需要重写，意味着以前有关Silverlight的技术积累统统作废，意味着公司人才流失的可能性增大。&br&&br&因此，一旦听说微软又推出新的开发技术，项目经理或老板心里都会咯噔一下，这些人针对提主问题，更多的是被微软坑后的一种调侃。
以上几个答案都有点站着说话不腰痛。
微软干掉某项技术已经不是一次两次了，所以一有新东西推出，大家就有狼来了的感觉。
对于个人，无所谓，大不了花几个月重学一门新技术。但是对于公司，失去的就不仅仅是重新学习的成本。
例如，公司花了几个月做…
这不是理想状况吗？我的工作也是你这种情况，所以我能从&a href=&///?target=http%3A//ASP.NET& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&ASP.NET&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&瞬间转到WPF工作啊。你看赵三本里面哪本是关注&a href=&///?target=http%3A//ASP.NET& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&ASP.NET&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&或WPF这种所谓成熟技术的？而且更要说起来，哪有比语言和运行时和基础类库这类更成熟的部分呢？
这不是理想状况吗？我的工作也是你这种情况，所以我能从瞬间转到WPF工作啊。你看赵三本里面哪本是关注或WPF这种所谓成熟技术的？而且更要说起来，哪有比语言和运行时和基础类库这类更成熟的部分呢？
&a href=&///?target=http%3A///questions/1515800/display-select-users-and-groups-dialog-from-wpf-application& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Display &Select Users and Groups& dialog from WPF application?&i class=&icon-external&&&/i&&/a&&br&&br&要学会合理使用必应搜索引擎
要学会合理使用必应搜索引擎
看了看问题的提问者，发现又是一个作者自问自答夹带私货的帖子。可怜还有这么多人认真答题……你看看他的评论：”做技术要向前看, 别把几十年前那种一堆标签页和控件的UI带到新世纪里来“，不就是说新的程序都应该按照他的审美观写么？可惜审美观这东西永远不会有一致意见，但是可以肯定是是改变界面一定有大把的人反对（参考Office 2007和Windows 8)。而且这个和在HTML5/WPF之间选择有什么关系？又没有人规定MFC/WinForms/WPF/HTML5的程序该写成什么样子。从Metro风格扁平方块动画满地跑到一堆标签页和控件的UI风格这些引擎都可以做。&br&&br&只要市场够大，有钱赚，微软就可以推。至于这个市场有多大，看看有多少招聘广告要求WPF，看有多少基于WPF的第三方组件产品广告，看技术论坛上每个月有多少关于WPF的问题就知道了，和提问者的一厢情愿一点关系都没有。微软在致力于将旧的基于GDI的程序（例如MFC和Windows Forms）迁移到基于DirectX的WPF，这个工作做了10年，进展不是很大，像Evernote这样的程序嫌WPF太慢又换回去了，反正简单的界面没动画也不需要多大显卡资源，改C++性能更好还可以跨平台。但是只要CPU的速度瓶颈一直不解决，界面发展的未来还是在GPU上，这方面微软的决策还是有根据的。&br&&br&至于扯HTML5跨平台什么的，你前端用Android后台用LAMP不给微软交钱的话，微软为什么要推广你的东西？没人说你自己的东西不好，你自己去掏腰包宣传啊。要微软掏腰包你要给微软生态系统贡献才行，比如后台放在Azure上啊，或者前端支持Windows API啊，不过说到推广力度嘛，当然是推只支持Windows平台的WPF对销量更有帮助了。在这里给自己的HTML5引擎打广告的，省省吧，微软推不推WPF，和你的引擎可以做的多么的炫，一点关系都没有。&br&&br&用性能需求强迫用户升级硬件的，也就操作系统可以干干，一个应用商这么干不是找删么？认为HTML可以解决一切开发需求的错误，苹果犯过（IPhone1最初不支持原生应用）,HP犯过(Web OS的平板发布后应用太少。最后不得不抛售），Facebook也犯过（CEO马克·扎克伯格称利用HTML5技术开发移动应用是该公司最大的错误决策之一），最后都是性能跟不上不得不放弃。另外，HTML5能不能跑还得看各家的HTML引擎的实现（比如&a href=&///?target=http%3A///article/2612281/html5/bad-news--ios-7-s-html5-is-full-of-bugs.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Bad news: iOS 7's HTML5 is full of bugs&i class=&icon-external&&&/i&&/a&），一次编写处处运行？Java早就证明这不过是一次编写处处调试罢了。&br&&br&评论中一些人满口喷粪，已经删除。
看了看问题的提问者，发现又是一个作者自问自答夹带私货的帖子。可怜还有这么多人认真答题……你看看他的评论：”做技术要向前看, 别把几十年前那种一堆标签页和控件的UI带到新世纪里来“，不就是说新的程序都应该按照他的审美观写么？可惜审美观这东西永远…
&p&对，你要把图片先嵌入到resource里面，然后给他一个key，然后在代码里引用这个resource，然后去访问这个key。具体过程我忘记了，自行bing攻略。&/p&
对，你要把图片先嵌入到resource里面，然后给他一个key，然后在代码里引用这个resource，然后去访问这个key。具体过程我忘记了，自行bing攻略。
已有帐号？
无法登录？
社交帐号登录}