我正在开发一个Windows Mobile应用程序,我遇到了一个问题CCommandBar,它结合了工具栏和菜单栏.嗯,我的意思是:
m_wndCommandBar.InsertMenuBar(IDR_MAINFRAME);
m_wndCommandBar.LoadToolBar(IDR_MAINFRAME);
我的命令栏中只有一个根菜单选项和工具栏中的一些按钮.它在Windows Mobile 6.5.3版本上运行完美,但在WM 6.5.3上,所有工具栏按钮都与菜单项具有相同的尺寸:http://transaq.ru/cl_files/problem.png
是否有可能强制WM 6.5.3以与WM 5.0相同的方式绘制命令栏？当然,我只能使用工具栏并扔掉我的菜单栏,但我想保留旧的UI.
我偶然发现了着名的Yen对Bellman-Ford算法的优化,这是我最初从维基百科得到的,然后我在练习部分的几本教科书中找到了相同的改进(例如,这是Cormen的24-1问题和在Sedgewick的网络练习N5 "算法").
这是改进:
Yen的第二个改进首先在所有顶点上分配一些任意线性顺序,然后将所有边的集合划分为两个子集.第一个子集Ef包含所有边(vi,vj),使得i <j; 第二个,Eb,包含边(vi,vj),使得i> j.按照v1,v2,...,v | V |的顺序访问每个顶点,从Ef中的那个顶点放宽每个输出边缘.然后按照v | V |,v | V | -1,...,v1的顺序访问每个顶点,从Eb中的那个顶点放宽每个输出边缘.算法的主循环的每次迭代,在第一次迭代之后,将至少两个边缘添加到边缘集合,其宽松距离匹配正确的最短路径距离:一个来自Ef,一个来自Eb.这种修改从| V |减少了算法主循环的最坏情况迭代次数 - 1到| V |/2.
不幸的是,我没有设法找到这个绑定| V |/2的证明,而且,似乎我找到了一个反例.我确信我错了,但我看不清楚到底在哪里.
反例只是一个路径图,顶点标记为1到n和初始顶点1.(因此,对于i,E = {(i,i + 1)}的范围从1到n-1).在这种情况下,前向顶点集合等于E(E_f = E),后向顶点集合只是空集合.算法的每次迭代仅添加一个正确计算的距离,因此算法在n-1时间内完成,这与提出的约束n/2相矛盾.
我究竟做错了什么？
UPD:所以这个错误非常愚蠢.我没有考虑通过顶点的迭代,考虑迭代直接更新路径成本.我不是删除这个主题,因为有人对它进行了投票,以防这种改进对某些人来说很有意思.
我有一个用Windows-1251编码编写的dll项目,我需要用UTF-16编码的dll输出.我使用以下函数进行转换:
ptr = MultiByteToWideChar(CP_ACP, 0, str, -1, wbuff.getBuffer(), len);
不幸的是,MultiByteToWideChar使用系统区域设置作为源编码.因此,例如,如果我的Windows语言环境是英语(美国),它会根据需要转换Win1252-> UTF8,而不是Win1251-> UTF8.
我尝试手动设置区域设置,但以下代码也不起作用:
enc = setlocale(CL_ALL, "rus_rus.1251");
//this returns Windows-1251 encoding
ptr = MultiByteToWideChar(CP_ACP, 0, str, -1, wbuff.getBuffer(), len);
据我所知,MultiByteToWideChar总是使用系统区域设置,忽略我的setlocale调用.
还有其他方法可以进行此类转换吗？或者我可能只是不理解这些区域设置？谢谢.
PS我很抱歉语法错误.