Visual Studio Code调试Python无法Step Into导入(imported)模块的代码

Visual Studio Code调试Python无法Step Into导入(imported)外部模块的代码,导致在跟踪调用流程的时候非常不方便。

这个现象是Visual Studio Code为了防止调试的时候过多的关注不相干代码,因此默认禁止跟踪外部模块代码,只跟踪我们自己工程内部的代码。

禁止这部分功能,只需要在工程的配置文件launch.json中增加"justMyCode": false即可。

如下:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "Python: 当前文件",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false
        }
    ]
}

参考链接


Windows 路径相关的ShellApi

路径截断与合并函数
PathRemoveArgs 去除路径的参数
PathRemoveBackslash 去除路径最后的反斜杠"\"
PathAddBackslash 在路径最后加上反斜杠"\"
PathRemoveBlanks 去除路径前后的空格
PathAddExtension 在文件路径后面加上扩展名
PathRemoveExtension 去除文件路径扩展名
PathRenameExtension 更改文件路径扩展名
PathRemoveFileSpec 去除文件名,得到目录
PathUnquoteSpaces 去除路径中的首尾空格
PathQuoteSpaces 判断路径中是否有空格,有的话,就是用""引号把整个路径包含起来
PathAppend 将一个路径追加到另一个路径后面
PathCombine 合并两个路径
PathSkipRoot 去掉路径中的磁盘符或UNC部分。
PathStripPath 去掉路径中的目录部分,得到文件名。
PathStripToRoot 去掉路径的文件部分,得到根目录。
   
PathCompactPath 根据像素值生成符合长度的路径。如原始路径:C:\path1\path2\sample.txt
根据120像素截断后为:C:\pat...\sample.txt
根据25像素截断后为: ...\sample.txt
PathCompactPathEx 根据字符个数来生成符合长度的路径。
   
PathSetDlgItemPath 将路径数据设置到对话框的子控件上。
PathUndecorate 去除路径中的修饰——具体还没看明白,的例子只是去掉了括号。
PathUnExpandEnvStrings 将路径中部分数据替换为系统环境变量格式
路径查找比较函数
PathFindOnPath 从路径中查找路径
PathFindExtension 查找路径的扩展名
PathFindFileName 获取路径的文件名
PathFindNextComponent 查找匹配路径(不太熟悉)
PathFindSuffixArray 查找给定的文件名是否有给定的后缀。
PathGetArgs 获取路径参数
PathGetCharType 获取路径字符类型
PathGetDriveNumber 根据逻辑盘符返回驱动器序号
路径转换函数
PathRelativePathTo 创建一个路径到另一个路径的相对路径。
PathResolve 将一个相对路径或绝对路径转换为一个合格的路径,这个理解起来比较拗口。
PathCanonicalize 规范化路径。将格式比较乱的路径整理成规范的路径格式。
PathBuildRoot 根据给定的磁盘序号创建根目录路径
CreateDirectory 创建目录
   
GetShortPathName 将长路径转为8.3格式的短路径格式
GetLongPathName 将短路径格式转为长路径。
PathGetShortPath 将长路径转为短路径格式(8.3格式)
PathCreateFromUrl 将URL路径转为MS-DOS格式
PathMakePretty 把路径全部转为小写,增加可读性。
PathMakeSystemFolder 给路径增加系统属性
PathUnmakeSystemFolder 去除路径中的系统属性。
PathMakeUniqueName 从模板创建统一的路径格式——没用过,不熟悉
PathProcessCommand 生成一个可执行的路径,比如有参数的,会自动将路径用""包含。这在ShellExecute中比较有用。
路径验证函数
PathCleanupSpec 去除路径中不合法的字符
PathCommonPrefix 比较并提取两个路径相同的前缀
PathFileExists 验证路径是否存在
PathMatchSpec 判断路径是否匹配制定的扩展名。
PathIsDirectory 判断路径是否是一个有效的目录
PathIsFileSpec 验证路径是否一个文件名(有可能是一个路径)
PathIsExe 验证路径是否是可执行文件。注意:不仅仅是.exe,还有.bat,.com,.src等
PathIsRoot 路径是否为根路径
PathIsRelative 判断路径是否是相对路径
PathIsContentType 检测文件是否为制定类型。
例如:PathIsContentType("hello.txt", "text/plain") 返回TRUE
PathIsContentType("hello.txt", "image/gif") 返回FALSE
PathIsHTMLFile 判断路径是否是html文件类型——根据系统注册类型判断。
PathIsLFNFileSpec 判断路径是否是长路径格式
PathIsNetworkPath 判断路径是否是一个网络路径。
PathIsPrefix 判断路径是否含有指定前缀
PathIsSameRoot 判断路径是否有相同根目录
PathIsSlow 判断路径是否是一个高度延迟的网络连接——我也不太明白是啥意思。
PathIsSystemFolder 判断路径是否有系统属性(属性可以自己设定)
PathIsUNC 路径是否是UNC格式(网络路径)
PathIsUNCServer 路径是否是UNC服务器
PathIsUNCServerShare 路径是否仅仅是UNC的共享路径格式
PathIsURL 路径是否是http格式。
PathYetAnotherMakeUniqueName 基于已存在的文件,自动创建一个唯一的文件名。比较有用,比如存在"新建文件",此函数会创建文件名"新建文件(2)"。

参考链接


windows 路径相关的shell api

在Visual C++ 2015 中使用Tab Control控件

系统环境:Windows 7
软件环境:Visual Studio 2015 Udpate 2
本次目的:在模态或非模态对话框中使用Tab Control控件,及引申在单/多文档中使用

查阅MSDN文档,对于创建Tab Control控件,MSDN上说明如下:

To use CTabCtrl directly in a dialog box
1. In the dialog editor, add a Tab Control to your dialog template resource. Specify its control ID.
2. Use the Add Member Variable Wizard to add a member variable of type CTabCtrl with the Control property. You can use this member to call CTabCtrl member functions.
3. Map handler functions in the dialog class for any tab control notification messages you need to handle. For more information, see Mapping Messages to Functions.
4. In OnInitDialog, set the styles for the CTabCtrl .
To use CTabCtrl in a nondialog window
1. Define the control in the view or window class.
2. Call the control's Create member function, possibly in OnInitialUpdate, possibly as early as the parent window's OnCreate handler function (if you're subclassing the control). Set the styles for the control.

 

对话框内使用CTabCtrl


1. 在对话框编辑区内,添加一个Tab Control控件到资源模板里面,设置它的控制ID
2. 使用添加成员变量向导,为控件添加一个CTabCtrl类型的成员变量,你可以使用这个变量调用CTabCtrl的成员函数
3. 对话框类的映射处理功能可以处理任何你需要处理的标签控件消息。有关更多信息,请参阅消息映射函数。
4. 在OnInitDialog()函数里面,设置CTabCtrl的风格。

非对话框窗口使用CTabCtrl


1. 定义在视图或窗口类的控件。
2. 调用控件的创建成员函数,可能在OnInitialUpdate中,可能在父窗口的OnCreate处理函数早期(如果你是子类的控件)。设置控件的风格。
下面介绍在对话框中添加Tab Control控件,工程不一定是要MFC基于对话框形式,单文档视图类派生自 CFormView的工程也行,或是任何工程弹出的对话框 ( 如登录界面等等 ) 都行 ( 个人没有都去实验,但理论上应该可以,看了下面就知道。 )
1. 首先在对话框资源上添加一个Tab Control控件IDIDC_LOGIN_TAB,根据需要修改其属性,然后为其添加成员变量m_tab,类型为CTabCtrl
2. 需要几个选项卡,则在对话框资源添加几个对话框,在这里我添加两个选项卡,则要添加两个对话框,其ID分别为 IDD_TAB1_DIALOGIDD_TAB2_DIALOG它们的属性styleChild,BorderNone,其他的再根据自己调整。然后分别为其添加对应的基于CDialogCLoginTab1CLoginTab2
3. 在主对话框添加子对话框头文件,然后再添加三个成员变量,为子对话框添加实例。在OnInitDialog()函数初始化Tab Control控件显示,若对话框没有OnInitDialog()函数,则重载这个函数,具体如下:
//主对话框头文件

class LoginUser : public CDialog
{
	...
	protected:
	virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV 支持
	virtual BOOL OnInitDialog(); //没有这个,则在这里重载
	DECLARE_MESSAGE_MAP()
	public:
	CTabCtrl m_tab;
	CLoginTab1 m_login_tab1;
	CLoginTab2 m_login_tab2;
	...
}

//主对话框实现文件

BOOL LoginUser::OnInitDialog()
{
	CDialog::OnInitDialog();
	m_tab.InsertItem(0,_T("系统登录"));
	m_tab.InsertItem(1,_T("服务器设置"));
	m_login_tab1.Create(IDD_TAB1_DIALOG,GetDlgItem(IDC_LOGIN_TAB));
	m_login_tab2.Create(IDD_TAB2_DIALOG,GetDlgItem(IDC_LOGIN_TAB));
	//获得IDC_TABTEST客户区大小
	CRect rs;
	m_tab.GetClientRect(&rs);
	//调整子对话框在父窗口中的位置,根据实际修改
	rs.top+=25;
	rs.bottom-=60;
	rs.left+=1;
	rs.right-=10;

	//设置子对话框尺寸并移动到指定位置
	m_login_tab1.MoveWindow(&rs);
	m_login_tab2.MoveWindow(&rs);
	//分别设置隐藏和显示
	m_login_tab1.ShowWindow(true);
	m_login_tab2.ShowWindow(false);

	//设置默认的选项卡
	m_tab.SetCurSel(0);
	return TRUE;
}

4. 响应选项卡切换事件消息,右键Tab Control控件,添加事件处理程序,选择TCN_SELCHANGE事件,在弹出的编辑区域,填入以下代码:

void LoginUser::OnTcnSelchangeLoginTab(NMHDR *pNMHDR, LRESULT *pResult)
{
	// TODO: 在此添加控件通知处理程序代码
	int CurSel = m_tab.GetCurSel();
	switch(CurSel)
	{
	case 0:
	m_login_tab1.ShowWindow(true);
	m_login_tab2.ShowWindow(false);
	break;
	case 1:
	m_login_tab1.ShowWindow(false);
	m_login_tab2.ShowWindow(true);
	break;
	default: ;
	}
	*pResult = 0;
}

5. 编译运行。

22

接下来,来看看非模态对话框的实现,因为Tab Control控件要在对话框的OnInitDialog()函数初始化,而MSDN上说:

After the dialog box and all of its controls are created but just before the dialog box (of either type) appears on the screen, the dialog object's OnInitDialog member function is called. For a modal dialog box, this occurs during the DoModal call. For a modeless dialog box, OnInitDialog is called when Create is called. You typically override OnInitDialog to initialize the dialog box's controls, such as setting the initial text of an edit box. You must call the OnInitDialog member function of the base class, CDialog , from your OnInitDialog override.

非模态对话框是在Create的时候一起调用初始化函数的,OnInitDialog()我们仍可以重载这个函数,来实现以上功能。对于单文档/多文档可以看前面的MSDN说明,这里不再详细写。本文若有错误,请指出。

参考链接


在VC++中使用Tab Control控件

warning C4743: “const std::ios_base::failure::`vftable'”有不同的大小: 16 和 12 字节

最近在使用VS2013进行静态库链接的时候,发现在最后链接的时候,编译器报告如下警告

4>LINK : warning C4743: “const std::system_error::`vftable'”在“aaa.cc”和“bbb.cpp”中具有不同的大小:  16 和 12 字节
4>LINK : warning C4743: “const std::_System_error::`vftable'”在“ccc.cc”和“ddd.cpp”中具有不同的大小:  16 和 12 字节
4>LINK : warning C4743: “const std::ios_base::failure::`vftable'”在“eee.cc”和“fff.cpp”中具有不同的大小:  16 和 12 字节
4>LINK : warning C4743: “const std::runtime_error::`vftable'”在“xxx.cc”和“yyy.cpp”中具有不同的大小:  16 和 12 字节

尽管这个是个警告,但是由于涉及到vftable 的问题,这个问题会导致对象指针之间相互赋值的时候导致内存布局混乱,非常可能导致严重的问题。因此这个警告的危险级别甚至比错误的还要严重,绝不能简单的忽略这个问题。

研究了很久,发现,在Debug版本上面是没有问题的,但是Release版本上面必然出现该问题。并且当设置VC++ 的 “工程属性->配置属性->C/C++->优化->全程序优化”为 “否”的时候,也是可以无警告链接通过的。但是却会导致我们的工程损失更多的优化,降低运行效率。

这个问题产生的原因是一个宏引起的,这个宏就是 “_HAS_EXCEPTIONS=0” 。这个宏控制了STL对于异常的处理流程,影响着typeinfo,system_error 等几个文件中对于VC 运行时库的链接选择,要么链接libcmt.lib,要么链接msvcrt.lib。比较不凑巧的是,微软在实现这两个库的时候,其中一个比另外一个多了一个虚函数。(这种情况不应该发生,但是确实发生了!)

因此,如果我们的LIB工程定义了“_HAS_EXCEPTIONS=0” ,那么所有使用我们这个LIB的项目,都要定义这个宏。

对于简单的项目,只要都定义“_HAS_EXCEPTIONS=0” 就可以解决问题。但是对于复杂的工程,尤其是依赖了大量的第三方的已经编译过的,没有源代码的LIB项目来说,只能是采用妥协的办法,所有的工程都取消这个宏的定义,使得两者的内存布局相同。毕竟,稳定性是第一需求。