精品91免费,欧美久久99,亚洲国产精品成人综合色在线婷婷

duguguiyu — Sat, 21 Jul 2007 13:43:00 GMT

在做一个MFC软�g的时候有一个这��L��需求，��是要有�c�M��与AutoCad的命令输入框�Q�如下图所�C�：

本着不重写已有功能的原则�Q�在MFC中发掘了一圈，没发现有可用的现成控�Ӟ��上网搜了一下，发现有�h做过�Q�但竟然�q�收费出售，so faint�Q�只能自己动手做一个�?/p>

其实思�\�q�是蛮简单的�Q�就是放个Edit控�g处理它的键盘输入事�g�Q�防止删除之前的记录和提�C�Z��息，�q�要处理�l�束命��o�Q�比如回车、空��g��cȝ��。主要有以下几个步骤�Q?/p>

1. ��输入框内的字符串分�D�，比如分成三段log, tip和command�Q�前两段都不能被修改�Q�command的内容�ؓ可修改的。在�l�束了command输入后，要同步各字符�Ԍ��C�Z��代码如下�Q?/p>

void CMainFrame::InitCommand(CString tip)
{
// 记录老字�W�串�Q�类��g��UpdateData(true)

this->GetText();

// 讄��新的log
if(this->m_log != "")
this->m_log += "\r\n";
this->m_log += tip;

// 更新字符�Ԍ��c�M��与UpdataData(false)
this->SetText();

// ��光标置于字�W�串的尾部（否则光标会在一开始的位置�Q?/p>
((CEdit *)m_commandDialogBar.GetDlgItem(IDC_COMMAND))->SetSel(this->m_log.GetLength(),
this->m_log.GetLength());
}

2. 重蝲PreTranslateMessage事�g�Q�处理键盘信息，�C�Z��代码如下�Q?/p>

BOOL CMainFrame::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message == WM_KEYDOWN) // 处理键盘按下事�g
{
  // 判断是否是在脚本输入框上输入�?/p>
  if(GetFocus() == m_commandDialogBar.GetDlgItem(IDC_COMMAND))
  {
   // 如果选择的是非正在输入的文字�Q�抛弃这个事�?/p>
   DWORD selectedRegion = ((CEdit *)m_commandDialogBar.GetDlgItem(IDC_COMMAND))->GetSel();
   int selectedStart = LOWORD(selectedRegion);
   int selectedEnd   = HIWORD(selectedRegion);

   if(selectedStart != selectedEnd && selectedStart < m_log.GetLength())
    return true;

   if(pMsg->wParam == 8 && selectedStart <= m_log.GetLength()) // ��L��删除之前的文�?br goog_ds_charIndex="1307">    return true;

   if(pMsg->wParam == 13 || pMsg->wParam == 32) // 当输入空格或回�R是发送消�?br goog_ds_charIndex="1390">    this->SendCommand();
  }
}

return CMDIFrameWnd::PreTranslateMessage(pMsg);
}

其中SendCommand的内容可自定义，处理完成后不要忘记执�?的操作，同步一下字�W�串��O(ji��n)K。实现效果如下：

当然�Q�这是一个最��单的实现�Q�还有很多问题没有处理，比如自定义菜单，屏蔽�pȝ��菜单�{�；�q�有很多工作可以做，比如��装成一个自定义控�g�Q�做更好的显�C�效果等�{�。但基本的思�\�q�是一��L��Q�恩�Q�如果谁有更好的实现�Ҏ(gu��)��Q�也�Ƣ迎留言�Q�谢谢先�Q�）

duguguiyu 2007-07-21 21:43 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826901.html

duguguiyu 2007-07-21 21:43 发表评论

duguguiyu — Sat, 21 Jul 2007 13:04:00 GMT

在VC++中有着一大把字符串类型。从传统的char*到std::string到CString�Q�简直是多如牛毛。期间的转换�怿�也是�l�晕了许多的人，我曾��是其中的一个。还好，MS�q�没有��失功德心�Q�msdn的一��文章详�l�的解析了各�U�字�W�串的�{换问题，链接如下�Q?a goog_ds_charIndex="129">http://msdn2.microsoft.com/zh-cn/library/ms235631(VS.80).aspx�?/p>

参照�q�篇文章�Q�可以搞定同码制的字�W�串转换�Q�如果有unicode到非unicode的�{换问题，�q�需要另寻高招。我通常��是归一化，把工�E�属�?->General中的Character set�l�一选�ؓno set或unicode。每每此�Ӟ��我都会出奇的惛_��C#。。�?/p>

duguguiyu 2007-07-21 21:04 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826869.html

duguguiyu 2007-07-21 21:04 发表评论

MFC的非模态对话框资源��理

duguguiyu — Sat, 21 Jul 2007 12:56:00 GMT

非模态对话框比模态对话框更难使用�q�是众所周知的，�q�是�׃��模态对话框�q�行�Ӟ��d��了其父窗口的消息循环�Q��其能自成一�z�，所以能够怡然自得。但非模态对话框只相当于一个由父窗体创建的一个同�U�的Hwnd�Q�就像一个长大了的孩子，可以和父母�ƈ��N��׃��Q�需要父母管又不能管的太厉害�Q�其资源��理、通信都会比模态的更�ؓ复杂�?nbsp;

很多时候，能用模态对话框的情况下�Q�都会用模态的。虽�?a title=Copper target=_blank>Copper 老先生指着��d��苦口婆心的教��g��我们�Q�但有时候�h懒脸皮也��厚了，无所谓了。但�Q�世界��L��很残��P��很多时候（比如需要在处理对话框事件的时候也能响应窗体事�Ӟ��Q�我们不得不去面寚w��模态对话框。其实了解了资源��理的模式，��像扒开了非模态对话框半遮的琵�Ӟ��可以很坦然的面对了�?/p>

模态对话框的资源分成两�U�，一�U�是内存资源�Q�一�U�是非内存资源。单看非内存资源的管理，其实和内存资源的��理原理是一��L��。在C++中，内存资源的管理讲�I�new和delete配对�Q�同理，非内存资源的��理需要create和destroy出双入对。在�q�篇文章中，基本体现了非模态对话框资源��理的一个基本模式，卛_��存资源管理和非内存资源同步�?

�q�样通过判断内存资源是否占用�Q�即指针是否为空�Q�就可以判断非内存资源的使用状况。当指针为空�Q�说明对话框�q�未创徏�Q�非内存资源未申��P��Q�当指针不�ؓ�I�，对话框已创徏�Q�正处于可见或不可见状态。这样将两部分资源管理合�q�在一起了�Q�只需要判断指针是否�ؓ�I�就可以了解对话框资源的状态。一些内存管理的手段�Q�比如类��理思想�Q�将delete和destroy攑ֈ��cȝ��析构函数中）�Q�可以实现资源的自动��理�?

��Z��实现�q�种��理模式�Q�要注意以下几点�Q?

1. 在堆上分配非模态对话框的内存资源，通俗一点的描述��是不要用这�U�方式：CXXDialog t;而是用这�U�方式：CXXDialog *t = new CXXDialog();来分配内存�?

2. 同步构造和析构�q�程�Q�就是说有new一定配上个create�Q�delete一定要勾搭一个destroy�?

3. 被delete的内存指针一定要�|�空�Q�也��是下面两句要接�t�而至�Q�delete xx;和xx == null;。其实这也是普通的内存��理需要遵循的一个良好习惯�?

了解了这些，非模态对话框也会只有温柔没有狰狞�?/p>

duguguiyu 2007-07-21 20:56 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826858.html

duguguiyu 2007-07-21 20:56 发表评论

duguguiyu — Sat, 21 Jul 2007 11:37:00 GMT

在C++中经�怼�涉及到处于不同头文�g的类互相引用的情况，有时候头文�g引用�Q�include�Q�会搞得很�ؕ�Q�导致报一堆的错。其实遵循一定规则，可以避免大部分的混�ؕ�?/p>

首先�Q�要对头文�g�q�行处理�Q�保证不会出现重定义的错误。这个应该每个�h都会�Q�通常有两�U�做法：

1. �?cpp文�g中添加保护，比如�?cpp文�g中添加：

#ifndef _XX_H_
#define _XX_H_
#include "xx.h"
#endif

2. �?h中添加保护，比如在xx.h文�g中添加：

#ifndef _XX_H_
#define _XX_H_
// 头文件声明内�?br goog_ds_charIndex="284">#endif

_XX_H_是我比较习惯的命名方式，其他的命名方式，比如__XX__H__�Q�XX_H�{�等�Q�只要��够Unique��好。徏议��用第二种方式�q�行重定义的保护�Q�一��x��逸而且��h��通用性，��M��人拿来就能用�Q�不需要考虑保护问题。当�Ӟ��如果在VS�Q?3以上吧？�Q�下�Q�最好的解决�Ҏ(gu��)��是用#pragma once�Q�更为简单有效�?/p>

其次�Q�最好将所有头文�g需要用到的自定义类�Q�或函数�Q�都在定义前声明一下，比如在xx.h的类xx中需要用到yy.h中的yy�c�，那么最好做以下的处理：

class yy;

class xx
{
// 实现内容
};

�q�样��可以保证头文�g引用的次序不会对�l�果造成影响�?/p>

通常�Q�保证以上两点，通常涉及到类互指的问题都可以解决。当然如果天生就有设计问题，无论如何都是没有办法的，比如�Q?/p>

// xx.h
class xx
{
yy t;
};

// yy.h
class yy
{
xx t;
};

不难看出�Q�这是个递归定义�Q�编译器无法��定�c�xx和yy的大��，��无法通过�~�译。一�U�解决策略是采用指针�Q�比如：

// xx.h
class xx
{
yy* t;
};

// yy.h
class yy
{
xx* t;
};

当然�Q�具体情况具体分析，提取一个更高层的类�{�手�D�都可以考虑�?/p>

�q�有一个问题，我一直也心存疑问�Q�就是头文�g�l�织问题。在VS中徏立一个MFC工程�Q�都会��生一对stdafx文�g�Q�按照这�U�思想我们把工�E�下通用的头文�g都放入stdafx.h中，�?cpp文�g的最开始统一#include "stdafx.h"�Q�这样就可以�?h文�g中引用很��的头文件�?/p>

�q�种�{�略在单工程时很好用�Q�相当于做了头文件组�l��别的重用�Q�但它违反了我一直恪守的一个原则即谁的头文件谁负责�Q�指.h�?cpp各自负责各自所需的头文�g。于是在跨工�E�的时候会出现一些问题。比如在B工程B的某�?h中引用了工程B中的一个头文�g�Q�由于编译次序问题，�q�个头文件可能无法被�~�译。不知道大家都如何处理头文�g�l�织问题的，望指教�?/p>

duguguiyu 2007-07-21 19:37 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826821.html

duguguiyu 2007-07-21 19:37 发表评论

MFC控�g之CControlBar

duguguiyu — Sat, 21 Jul 2007 11:35:00 GMT

有时候我们经常把对话框和视图�l�合��h��Q�做成AutoCAD命��o输入框、PhotoShop��动框之�cȝ��效果。但很奇怪的是我看过的MFC的书上都没有特别说明�q�这��L��工作该如何去做，我刚接触MFC的时候都是通过控制非模态对话框来模拟的�Q�后来才知道�q�些工作是通过CControlBar的派生类来完成的。比如CDialogBar��是加蝲一个已有的对话框资源，嵌入Frame中，和视��N��合��用�?/p>

其实知道了有�q�么个东西，剩下的问题都不能�U�做问题了，其��用和CToolBar�c�M��Q�可以通过http://msdn2.microsoft.com/zh-cn/library/wc9sxcw1(VS.80).aspx下蝲MSDN�C�Z��Q�当然也可以在本机的MSDN搜烦CDialogBar获得�?/p>

duguguiyu 2007-07-21 19:35 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826819.html

duguguiyu 2007-07-21 19:35 发表评论

MFC动态菜单全�ȝ��

duguguiyu — Sat, 21 Jul 2007 11:34:00 GMT

做一个MFC�E�序的时候碰��C��个需求。就是需要根据定制情况，动态生成菜单，菜单的具体结构和信息是之前不知道的（因此不能利用工具构造）�Q�点��M��同类型的菜单会触发特定的一�c�M��Ӟ��需要动态绑定事�Ӟ��。这�U�需求实际是蛮不BT的，很多场合下都可能会有�Q�用C#写了个Demo�׃��不到半个��时。但转到MFC下来写，��p��周折。其实这个问题代表了在MFC中动态创��源绑定事件的一般性问题，所以�ȝ��一下�?/p>

动态创��单需要先�?strong style="FONT-WEIGHT: normal" goog_ds_charIndex="207">�?/strong>CMenu�c�R��通常我们利用工具�l�制一个菜单，每一个菜单项下都可以视�ؓ有一个CMenu�c�R��它们联�p�d��一��P��形成树状。典型的一个菜单对应过来是如下图这个样子：

如上�Q�CMenu可以分成三种�Q�一个是Popup�Q�黄�Ԍ��Q�一个是Separator�Q�灰�Ԍ��Q�一个是Item�Q�红�Ԍ��。前两种都是没有ID信息的，Popup有一个指针，指向其SubMenu�Q�Item保存各种信息有ID可以响应事�g�Q�Separator�Q�恩�Q�基本是一�I�二白的�?/p>

CMenu的CreateMenu�Ҏ(gu��)��可以创徏一个菜单资源，用DeleteMenu�Q�包含所有子菜单�Q�或DestoryMenu可以销毁菜单资源，用AppendMenu可以��d��一个菜单。了解这些内容，��可以开工了�Q�现实现上图所�C�的MainSubMenu1下菜单的动态创建，代码如下�Q?br goog_ds_charIndex="566">

    // 假设在ChildFrm中，调用该方法获得当前的主菜单指�?br goog_ds_charIndex="605">    CMenu* mainMenu = AfxGetMainWnd()->GetMenu();
    CMenu* subMenu = NULL;

    // 遍历主菜单下的各�U�菜单寻扑֐�为MainSubMenu1的菜�?br goog_ds_charIndex="724">
    int menuCount = mainMenu->GetMenuItemCount();

    for(int i = 0; i < menuCount; i++)
    {
        CString menuName;
        if(mainMenu->GetMenuStringA(i, menuName, MF_BYPOSITION)
            && menuName == "&MainSubMenu1")
        {
            drawingMenu = mainMenu->GetSubMenu(i);
            break;
        }
    }

    // �U�除原有的菜单项
    int subMenu1Count = subMenu->GetMenuItemCount();
    for(int i = subMenu1Count - 1; i >= 0; i--)
    {
        subMenu->DeleteMenu(i, MF_BYPOSITION);
    }

    // 动态添加Item菜单��?br goog_ds_charIndex="1248">    for(int i = 0; i < 2; i++)
    {

        CString message = "";

        subMenu->AppendMenuA(MF_STRING, ID_BEGIN + i, message.Format("SubSubMenu%i", i);

    }

    // ��d��分隔�W?br goog_ds_charIndex="1429">

    subMenu->AppendMenuA(MF_SEPARATOR);

    // ��d��弹出式子菜单

    CMenu * popupMenu = new CMenu();
    popupMenu->CreateMenu();
    for(int i = 0; i < 2; i++)
    {

        CString message = "";

        popupMenu->AppendMenuA(MF_STRING, ID_BEGIN + 2 + i, message.Format("PopupSubMenu%i", i));

    }
    subMenu->AppendMenuA(MF_POPUP, (UINT_PTR)popupMenu->operator HMENU(), "PopupMenu");

有几个需要注意的地方�Q�一个是主菜单的指针获得�Q�可以参�?a target=_blank>《MFC框架各部分指针获取方式�?/a>一文。另一个是Popup的菜单徏立，�{�略是分成两部分�Q�先new出内存在Create��源，�~�Z��不可。最后一个是为每个Item菜单合理分配ID�Q�这些ID��M��先预留出来，在MFC中，臛_��40000�?9000通常都是没�h用�?/p>

�q�也��引��Z��一个问题，卌��单事件的动态绑定。我们知道在.net中，事�g是真正动态绑定的�Q�而MFC中的事�g都是只能静态绑定，�q�是�׃��者的�~�译方式军_��的。所以，在MFC中需要定义菜单事�Ӟ��你需要先挖好坑（预留��_��ID�Q�，规定每个坑种什么罗卜（��不同类型的ID�l�定��C��同类别的事�g处理函数上）�Q�最后才能按坑种�|�卜�Q��ؓ执行相应事�g的菜单设�|�相应的ID�Q��?/p>

可以有两�U�方式来�l�定对应ID处理的事�Ӟ��一个是通过ON_COMMAND_RANGE宏（想一下ON_COMMAND宏会不会�z�上用场�Q�）在MessageMap里绑定批量处理事件的函数�Q�另一个是重蝲PreTranslateMessage函数�Q�截获�ƈ判断ID来进行处理。思想都是�c�M��的。值得注意的是�Q�通常�q�需要配套��用ON_UPDATE_COMMAND_UI_RANGE来保证动态创建的菜单Enable为True�Q�否则很可能菜单不可以点击（我就被郁闯��很久�Q�（�Q��?br goog_ds_charIndex="2382">

duguguiyu 2007-07-21 19:34 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/07/21/826816.html

duguguiyu 2007-07-21 19:34 发表评论

duguguiyu — Thu, 21 Jun 2007 17:33:00 GMT

前�h在CSDN�ȝ��的，曄��帮助�q�我�Q�整理�ȝ��一下，希望也能帮助一下别人�?/span>

	获得CWinApp	获得CMainFrame	获得CChildFrame	获得CDocument	获得CView
在CWinApp�?/strong>		AfxGetMainWnd() m_pMainWnd	AfxGetMainWnd()->MDIGetActive() AfxGetMainWnd()->GetActiveFrame()	SDI:AfxGetMainWnd()->GetActiveView()->GetDocument() MDI:AfxGetMainWnd()->MDIGetActive()->GetActiveView()->GetDocument()	SDI:AfxGetMainWnd()->GetActiveView() MDI:AfxGetMainWnd()->MDIGetActive()->GetActiveView()
在CMainFrame�?/strong>	AfxGetApp() theApp		MDIGetActive() GetActiveFrame()	SDI:GetActiveView()->GetDocument() MDI:MDIGetActive()->GetActiveView()->GetDocument()	SDI:GetActiveView() MDI:MDIGetActive()->GetActiveView()
在CChildFrame�?/strong>	AfxGetApp() theApp	GetParentFrame()		GetActiveView()->GetDocument()	GetActiveView()
在CDocument�?/strong>	AfxGetApp() theApp	AfxGetMainWnd()	AfxGetMainWnd()->MDIGetActive() AfxGetMainWnd()->GetActiveFrame()		POSITION pos = GetFirstViewPosition();GetNextView(pos)
在CView�?/strong>	AfxGetApp() theApp	AfxGetMainWnd()	GetParentFrame()	GetDocument()
在其他类�?/strong>	AfxGetApp()	AfxGetMainWnd()	AfxGetMainWnd()->MDIGetActive() AfxGetMainWnd()->GetActiveFrame()	SDI:AfxGetMainWnd()->GetActiveView()->GetDocument() MDI:AfxGetMainWnd()->MDIGetActive()->GetActiveView()->GetDocument()	SDI:AfxGetMainWnd()->GetActiveView() MDI:AfxGetMainWnd()->MDIGetActive()->GetActiveView()

理一理MFC的这几个�cȝ��关系�Q�可以很�Ҏ(gu��)��明白上面的这些�ؕ七八�p�的逻辑�?/div>

App是应用域�Q�所有的域中的东襉K��可以通过全局函数讉K��到它�?/div>

MainFrame是主框架�Q�也基本可以用全局函数讉K��到�?/div>

MainFrame下是若干个ChildFrame�Q�ChildFrame中若�q�个View和Document�Q�可能不成对�Q�，ChildFrame��理着View�Q�View和Document�q�行互操作�?/div>

因此整体框架��出来了�Q�一般除了直接应用的关系都可以通过MainFrame-->Active ChildFrame-->Active View-->Document�q�条�U�进行访问，�q�应该叫什么来自？万能�Ҏ(gu��)��吧^_^�?/div>

恕我懒惰�Q�不愿意��M��个更详细的图解，凑合着看看吧�?/div>

duguguiyu 2007-06-22 01:33 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/06/22/792511.html

duguguiyu 2007-06-22 01:33 发表评论

令我头疼的MFC命名

duguguiyu — Thu, 21 Jun 2007 15:18:00 GMT

最�q�在写一些关于MFC的东西，是因为做了些MFC的项目，一些零散的东西需要�ȝ��一下。但�q��ƈ不代表我有些喜欢他了�Q�其实还是蛮讨厌的。毕竟看�?Net Framework�Q�再看N多年前的MFC�Q�多��是有些不顺眼的。机理上的东西不敢多��_��有些变量和方法名字的讄��Q�站在FCL的设计角度看了，多少觉得有些不爽。也许是我太弱，也许是因为它的设计上考虑�q�是没有��_��的经验，列�D一些，�׃��׃��?

1. 在构造一个自定义的Dialog对象�Ӟ��我们会传入一个CWnd的指针进去，那个名�ؓpParent的对象。但当我在Dialog中调用GetParent函数的时候，无论传进的是什么指针（比如CYourView�Q�，得到的返回值都是指向CMainFrame的指针。曾�l�由于这个我调了N久的�E�序�Q�我承认�q�是�׃��我对MFC的了解不够造成的，但这名字也太��h��q�h��性了吧�?/p>

2. 当然�q�有臭名昭著的UpdateData函数�Q�很荣幸在这点上我和大师一��P��每次用到的时候都要停下来查看一下才能分清楚那个诡异的bool变量的意义。也许这在有IDE的时候不是问题，但问题是我看书的时候就会很�ȝ��了。分��L��两个明确命名的函敎ͼ�也许会好很多�?/p>

3. ShowWindow。恩��是它。看到这个名字，不熟�(zh��n)�MFC的�h应该都会觉得它是用来昄��一个窗口的。但...�Q�其实它兼有昄��和隐藏窗口的功能�Q�决定这一切的又是一个诡异的bool�?..

4. MoveWindow和SetWindowPos。这一对不够专注的兄弟。它们太强大了，所能做的事�q�不止Move和SetPos那么��单，当我��x��变一个窗体大��的时候，我翻来覆�ȝ��扑և�敎ͼ�万万没想刎ͼ�原来是这对名不副实的兄弟的工作，Faint...

5. GetWindowRect和GetClientRect。其实他们也许没有问题，有问题的是我�Q�我不喜�Ƣ用引用量代替一个貌似应该由�q�回值完成的东西...

6. SelectObject。�ؓ什么你传入一个新的Object�Q�它�q�回一个老的Object呢？不止我一个�h�Q�很多�h都被�q�个搞晕�q�，其实我也不明白，一个函数做两个函数的事�Q�这��实有点热心�q�度了吧...

7. afx_msg。一个永�q�都没被用到的预留量�Q�这��L��东西在MFC中有很多...

duguguiyu 2007-06-21 23:18 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/06/21/792426.html

duguguiyu 2007-06-21 23:18 发表评论

了解VS2005��Z��的MFC�E�序做的一些事

duguguiyu — Wed, 20 Jun 2007 16:20:00 GMT

利用MFC向导建立一个工�E�，然后开始编码。这��是我通常做一个MFC工程的开始。但向导可不是一个守规矩的东西，它会��Z��d��很多的代码，��Z��讄��大量的编译和链接选项。大部分时候这�U�工作是善意的，但是好心不一定办好事�Q�你不好好了解它�Q�它会给你带来很多的�ȝ��?/p>

在配�|�一个基于OpenCasCade的程序中�Q�我��遇��C��很多�ȝ��。MFC向导在它所生成的View, Document�{�架构类中都��d��了一�D�如下代码：

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

在Debug状态下�Q�VS会�ؓ你默认添加一个_DEBUG的预�~�译��）�Q�你在该�c�M��调用的new操作�W�都会被DEBUG_NEW所取代�Q�请警惕�q�个行�ؓ�Q�如果你重蝲�q�某个类的new�Q�很可能��׃��׃��它导致无法编译通过或运行不正确�?/p>

除此之外一些默认的讄��也要注意�Q�在VS2005中是默认支持Unicode的，它会在你的编译选项中加�?D "_UNICODE" /D "UNICODE"。这��׃��使得CString和你可能用到的std::string存在很麻烦的转换问题。你需要修攚w��目属性中General-->Character Set为not set�Q�将其设为ununicode�Q�保证与std::string的一��_��当然你还可以�q�用其他的解��x��法满��你的需求）�?/p>

有时候IDE也会“好心办坏�?#8221;�Q�比如在一个解��x��案中有两个工�E�，你�ؓA��d��B的编译依赖，在A的链接选项中就会�?zh��n)��?zh��n)�加上对B生成的dll的引用。当你某天整理代码取消了�q�个依赖的时候，你突然发现莫名的出现了很多link错误。不要慌张，在A中添加上B链接��就好了�Q�这��工作其实是你必��自己做的，只是你添加了依赖�~�译器非�怸�动的帮你完成了�?/p>

也许你看上面的错误都很简单，但如果不��心�Q�也许有天也会像我一��h��陷其中半天爬不出来。��M��Q�在天天用VS2005建MFC工程的时候，提前做好两�g事。一件是通读一遍系�l�默认生成的代码�Q�做到心中有敎ͼ�每一条莫名其妙的东西都要了解一下它的用途；另一件是在刚开始和改变了工�E�属性之后查看一下你的编译和链接命��o�Q�搞清楚它做了什么事�Q�有时候命令行虽然难记一点，但确实是一目了�Ӟ��你可以不必每天用命��o行编译程序，但一定要对这些命令心如明镜，了如指掌才好�?/p>

duguguiyu 2007-06-21 00:20 发表评论

文章来源:http://www.cnblogs.com/duguguiyu/archive/2007/06/21/791161.html