iCAx开思工具箱

标题: 请mizzle妹妹和其他的朋友看一看 [打印本页]

作者: skywood 时间: 2004-11-3 12:31
标题: 请mizzle妹妹和其他的朋友看一看
今天，我照着mizzle妹妹的大作：
【原创】嘿嘿针对skywoodug调用mfc对话框旧话重提https://www.icax.org/viewthread. ... 3D1&page=1#pid=做了一遍，结果出现了问题。

现在请mizzle妹妹和其他的朋友看一看。

版本：UG NX1.0    VC6.0 WinXP

作者: skywood 时间: 2004-11-3 13:50
第1步：建立合适的工程。

其实，从原理上说
MFC AppWizard(dll)、
Unigraphics NX AppWizard(dll)、
Win32 Dynamic-Link Library
三种选择都是可以的。
但是为了保险起见，我还是用了和mizzle妹妹一样的设置。

顺便说一下，mizzle妹妹建立工程的目录不是很好，原因是UG和其他一些软件不认中文字符和其他一些比

较少见的字符（例如“+”号）。像这样建立目录的话，输出的dll就不能被这些软件正确读取。

作者: skywood 时间: 2004-11-3 14:15
第2步：选择合适的dll。

在第1步中点击OK后，就出现了如下的画面。
其中，正规dll（Regular DLL）可以选择静态连接(statically linked)或动态连接。
正规dll，缺点是只能导出C风格的函数，但不能导出C++类、成员函数、重载函数；优点是可以被任何Win32编程环境装载（例如：甚至可以被VB6.0程序装载）。
扩展dll（Extension DLL）最大的优点是可以导出类。
UG/OPEN++声称支持C++，所以，应该可以同时支持正规dll和扩展dll。

mizzle妹妹的大作对此未作解释，所以我还是选择编译器默认的情况，即第2种dll（正规，动态）。

作者: skywood 时间: 2004-11-3 14:35
第3步：创建对话框。

“建立好工程后，插入一个对话框，由于欧门建立的是dll工程，所以生成的框架没带。在vc里的insert里的Resource里如图”。
这几句话我看得不是太懂。其实，不管建立的是exe工程或者dll工程，生成的框架都是不带对话框的。莫非mizzle妹妹和我有同样的爱好，建立exe工程时喜欢使用CFormView类？

现在言归正传，在编译器菜单中选择 insert --> resource --> Dialog --> NEW，创建对话框。

作者: skywood 时间: 2004-11-3 14:47
第4步：创建和对话框相联系的类。

双击刚才建立的对话框，就会转入如下画面。编译器问我们是建立新类还是使用已有的类。工程才建立，当然只能创建新类啦。

作者: skywood 时间: 2004-11-3 14:54
下面，我给新类取了一个和mizzle妹妹大作中一样的名称。但是名称字母的大小写有一个和她的不同，mizzle妹妹的叫 Cug_mfc_dlg，我的叫CUg_mfc_dlg。其实mizzle妹妹你看看别人写的书，大部分都喜欢将"C"后面的字母大写，这叫与国际接轨

。

作者: skywood 时间: 2004-11-3 15:04
现在先将工程编译一下看看，嗯，编译器问我们客户程序是哪一个，那么，也就是dll的联编没有问题了。

作者: skywood 时间: 2004-11-3 15:09
在上一步中，点击"Cancel"直接取消，然后打开相应的文件夹，看看，dll文件是不是已经存在了？

作者: skywood 时间: 2004-11-3 15:17
第5步：在工程文件ug_mfc.cpp中加入包含文件"ug_mfc_dlg.h" 、 <uf.h>
。

我没有在这一步加入其它内容，因为我上一次没有成功，这一次准备来个步步为营

。

作者: mizzle 时间: 2004-11-3 15:22
出现什么问题了？

作者: skywood 时间: 2004-11-3 15:22
第6步：再次尝试编译。

看，就出问题了！编译器说找不到 uf.h 文件。原来问题出在这里啊。

作者: skywood 时间: 2004-11-3 15:25
现在想想也是，编译器又不是我们肚子里的蛔虫，怎么会知道到哪里找uf.h文件呢？

下面开始了我们与编译器的单挑！

作者: skywood 时间: 2004-11-3 15:30
第1步：给uf.h加上路径。

作者: mizzle 时间: 2004-11-3 15:32
有没有在tool->option里的directories里面在选择show directories for下面选择include files里面把C:\PROGRAM FILES\EDS\UNIGRAPHICS NX\UGOPEN
加进来？这是我的ug的安装目录。
还有在show directores for里选择library files里也加入上面的路径。

作者: mizzle 时间: 2004-11-3 15:33
ft，不是那么加的吧，反正我是没那么加过，不知道对不对

作者: skywood 时间: 2004-11-3 15:36
编译试一试？

uf.h文件有了，但是那里又跳出来说，找不到 uf_defs.h文件。

原来，uf.h里面包含了uf_defs.h，这样的话我们不可能一个个给头文件加上路径，还是只有给编译器增加搜索路径。

作者: skywood 时间: 2004-11-3 15:50
第2步：增加搜索路径。

这个，我可没用过（是不是一个大水货？

）。

传统上，出于尊重他人的考虑，我会先试一试别人的方案。刚才看到mizzle妹妹的留言了，所以决定照她的办法做。

选择编译器菜单的 tools --> options... --> Directories ,然后加上本机中UG/OPEN的路径。如图：

作者: skywood 时间: 2004-11-3 15:52
好，dll可以正确编译！

作者: mizzle 时间: 2004-11-3 15:59
那你还有什么问题？
这不就可以了吗

作者: skywood 时间: 2004-11-3 16:01
那么，UG会承认这个对话框吗？

第7步：给dll加上与UG的接口。
在ug_mfc.cpp的最后加入：

extern "C" __declspec(dllexport) void ufusr(char *param, int *retcode, int rlen)
{

  UF_initialize();

  CUg_mfc_dlg dlg;
  dlg.DoModal();
  
  UF_terminate();
}

extern "C" int ufuser_ask_unload(void)
{
  return(UF_UNLOAD_UG_TERMINATE);
}

作者: skywood 时间: 2004-11-3 16:05
再次编译一下看看？

又出错了！

作者: mizzle 时间: 2004-11-3 16:11
你的输出目录在哪里？

作者: skywood 时间: 2004-11-3 16:13
现在还没有完成编译，也就是说，和输出路径无关。（输出路径只在dll可以生成的前提下，才能起到作用）

作者: mizzle 时间: 2004-11-3 16:27
或者你干脆把程序也用附件附上来吧

作者: skywood 时间: 2004-11-3 17:02
好的，另外，我给你发了一分（不好意思，那一份居然有2兆！，希望没有把你的邮箱撑破！）

作者: mizzle 时间: 2004-11-3 19:03
欧建议你以后仔细看看，嘿嘿，看看欧当时发的那个帖子的第8楼里的东东，偶特意强调了要在，project setting里的link里的object/libaray modules里加上libufun.lib libugopenint.lib ，你加上试一下，应该编译能通过了，你发给欧的已经通过了。
还有以后发东西，把文件夹里的debug删掉，这样就小多了。你的文件修改过了。你看看

作者: skywood 时间: 2004-11-3 19:27
你改过的程序仍然有问题，编译器说找不到 “libufun.lib“文件。

我将自己备份的程序改过后，编译出现的错误一样。

作者: skywood 时间: 2004-11-3 19:31
可是路径我实际上已经加上了。

作者: mizzle 时间: 2004-11-3 19:44
不是这里的说，是在如图里吧。你试着在external Depend文件夹里把原来的那个找不到的文件删除了，再重新加入呢，在我机器上是好使得。

作者: skywood 时间: 2004-11-3 20:07
我这里当然有加这两个lib啦。而且你在你自己贴出来的附件中也有加这两个lib。

问题应该不是出在这。

不过，我倒注意到你刚才贴出来的图中“Project options”和我贴出来的不一样。

作者: mizzle 时间: 2004-11-3 20:23
我原来发帖子的源文件，如果在你机器里编译不通过，那你考虑一下是不是你软件的毛病或者是其他什么的，在我这里是好使的

作者: skywood 时间: 2004-11-4 11:02
问题已解决，请mizzle妹妹看一看。

其实说起来也很简单，之所以在mizzle妹妹那里编译可以通过，在我这里却不行，主要是因为我这里lib的搜索路径少了一条。可是，这种编译器设置上的差异却无法通过源代码来体现。

这也给大家一个启示：如果源代码在不同的人那里有的通过、有的不通过，那么很可能是由于编译环境不同造成的。

作者: skywood 时间: 2004-11-4 11:04
这是编译后的结果。

作者: skywood 时间: 2004-11-4 11:11
不过可惜啊，UG不认这个dll。

先是dll的载入路径，mizzle妹妹看有没有问题。

作者: skywood 时间: 2004-11-4 11:13
然后是

作者: skywood 时间: 2004-11-4 11:18
大家不要以为输出路径有误ug_mfc.dll的路径是
E:\ug_mfc\Debug
UG应该认的。

另外，我将ug_mfc.dll拷贝到其他目录,如E:\ug_mfc.dll也一样出错。

作者: mizzle 时间: 2004-11-4 15:25
难道我的那个帖子在你那里也是吗，出错？
如果没出错，我希望你仔细看看，vc环境里的设置有什么不同，还有上网上搜一些相关的文章看看吧。自己动手解决的才能记得最清楚。
你的程序，我看了一下，把里面的一个设置改了，就没问题了。你改一下试一下。

作者: mizzle 时间: 2004-11-4 16:02
怎么样，解决了吗，也不冒个泡

作者: skywood 时间: 2004-11-4 18:58
mizzle妹妹，你刚才得的发言我已经看了。UG也可以接受我们做的dll了。

但是对37楼还是有两个问题想不明白：
1。图中让我们选择的是动态还是静态连接到MFC，我选择的是动态，你选择的是静态。
为什么动态不可以？如果真是静态或是动态的原因，为什么编译器说的是断言(assert)出错，而不是说其它的错误（例如：不接受动态连结的库？）？
2。照道理说，静态连接（statically linked）应该比动态的大。这是因为静态连接包含了它所需要的MFC的代码的拷贝，以后也可以独立于MFC使用。
David也说，“一个典型的Release版本静态连接的正规DLL大约为144KB左右。如果选择动态连结，大小可降到17KB左右，但必须保证适当的MFC DLL在目标机器上存在。“（他使用的是VC5.0）
可是，对于同样的代码，我如果选择静态连接，则dll高达1.25MB，即使是动态连结，也有104KB。比David的估计要大6——8倍！而且我们做的这个工程还只是一个架子，根本还没有加入实质性内容！

下面是mizzle妹妹帮我做好的工程最后的效果。

欢迎光临 iCAx开思工具箱 (https://t.icax.org/)