在退出子程序之前,我应该重新开始.CutCopyMode吗? [英] Should I turn .CutCopyMode back on before exiting my sub procedure?

查看:196
本文介绍了在退出子程序之前,我应该重新开始.CutCopyMode吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为了优化我的代码,我关闭了几个应用对象成员属性;一个特别是 .CutCopyMode属性

  Sub MyProcedure()
应用程序
.ScreenUpdating = False
.EnableEvents = False
.CutCopyMode = False
结束

'这里的代码很多

在我的子程序结束之前,我应该再次使用.CutCopyMode(其他True)再次与其他文件一起转换。

 '很多代码这里

应用程序
.ScreenUpdating = True
.EnableEvents = True
.CutCopyMode = True'< ~~ ???
结束
End Sub


解决方案

简单的答案是, Application.CutCopyMode = True 根本没有做任何事情,或者与您认为的相反。如果.CutCopyMode的当前状态为False,则将其设置为True不会打开跳舞边框,如果当前状态为xlCopy或xlCut( XlCutCopyMode枚举常量),将.CutCopyMode设置为True有效地将其关闭。此外,您不能将.CutCopyMode设置为xlCopy或xlCut。



长的故事开始于理解 Application.CutCopyMode属性执行,官方文档的错误意味着您可以将其重新打开。 >

当您手动剪切(Ctrl + X)或复制(Ctrl + C)工作表上的一个或多个单元格时,单元格将获取一个跳舞边框,表示源的操作。此时,.CutCopyMode不为零(xlCopy或xlCut),后续粘贴操作与Office剪贴板和Windows剪贴板之间的关系都存在,因为它们保留了源的内容。



如果您选择将单元格(Ctrl + V)粘贴(Ctrl + V)之后立即切割(或移动),则将单元格切换到新位置.CutCopyMode将变为false,并丢失跳舞边界。这是因为源单元格中没有任何内容。内容仍然可以从Office剪贴板访问,但是从Windows剪贴板中删除。



如果您选择复制单元格,则可以将单元格粘贴到其他位置, 跳舞边界遗体。 .CutCopyMode属性保持不为零(例如xlCopy)。您可以移动到另一个位置并粘贴相同的内容; .CutCopyMode保持非零,并且原始内容周围的跳舞边框与Office剪贴板和Windows剪贴板的关系一样。



如果您运行VBA在这一点上包括 Application.CutCopyMode = False 的代码,跳舞边框将消失,任何粘贴操作和Office剪贴板之间的连接将被消除。当启动VBA子过程时,这是一个很好的状态,以便代码中的任何潜在的复制/粘贴操作不会与.CutCopyMode状态潜在地冲突。但是,这仅在特殊情况下才需要(见下一段)。



某些Excel操作足以打破此Office剪贴板连接,并将.CutCopyMode强制为False。其中之一是手动启动宏子程序,因此在代码开头包含 Application.CutCopyMode = False 是有限的好处。但是,如果您的代码启动了,则可能谨慎运行您的代码Range.Copy 操作,您已完成任何 Worksheet.Paste方法 Range.PasteSpecial方法操作与内容的副本。



可以使用一些工作表事件宏代码来检查和报告.CutCopyMode的当前状态。

  Private Sub Worksheet_SelectionChange(ByVal Target As Range)
选择案例Application.CutCopyMode
案例True
Debug.PrintCutCopyMode为ON
案例xlCopy
Debug.PrintCutCopyMode处于复制模式
案例xlCut
Debug.PrintCutCopyMode处于剪切模式
Case False
Debug.PrintCutCopyMode为OFF
Case Else
Debug.Print???
结束选择
End Sub

结果报告给VBE的立即窗口可以是复印模式,剪切模式或关闭。 Application.CutCopyMode永远不会直接将其状态报告为True²。



虽然您可以通过 Application.CutCopyMode = False来影响操作环境的更改/ code>,通过将属性设置为True,我从未能够转到.CutCopyMode On 。没有发生错误,官方文档特别声明将属性设置为True 开始剪切或复制模式并显示移动边框。但是,我发现,唯一的方法是恢复行进蚂蚁'将要启动另一个复制操作。



所以对于所有意图和目的,编码 Application.CutCopyMode = True 没有伤害然而,编码 Application.CutCopyMode = False 可以通过放弃剪贴板存储来执行一些好处。



如果有人可以通过操作 Application.CutCopyMode财产,我会非常喜欢看一个例子。






¹跳舞边界虽然布尔值为True或False是一个不同的类型,但是对于所有意图和目的False等于零,并且任何东西不是假的是真的。如果解析布尔值,则VBA False为0,并且True始终等于(-1),但是如果解析反向号►布尔值,任何非零数字都将被视为True,零被认为是False。 p>

In order to optimize my code, I turn off several Application Object member properties; one in particular being the .CutCopyMode property.

Sub MyProcedure()
    With Application
        .ScreenUpdating = False
        .EnableEvents = False
        .CutCopyMode = False
    End With

    ' lots of code here

Should I turn .CutCopyMode back on (e.g. True) again with the others before my sub finishes?

    ' lots of code here

    With Application
        .ScreenUpdating = True
        .EnableEvents = True
        .CutCopyMode = True     '<~~ ???
    End With
End Sub

解决方案

The short answer is that Application.CutCopyMode = True either does nothing at all or it does the opposite of what you think it does. If the current state of the .CutCopyMode is False then setting it to True does not turn on the 'dancing border' and if the current state is either xlCopy or xlCut (XlCutCopyMode Enumeration constants), setting .CutCopyMode to True effectively turns it off. Additionally, you cannot set the .CutCopyMode to xlCopy or xlCut.

The long story starts with understanding just what purpose the Application.CutCopyMode property performs and how the official documentation wrong implies that you can turn it back 'on'.

When you manually cut (Ctrl+X) or copy (Ctrl+C) one or more cells on the worksheet, the cells will acquire a 'dancing border'¹ that indicates the source of the operation. At this point, .CutCopyMode is non-zero (either xlCopy or xlCut) and a relationship between subsequent paste operations and both the Office clipboard and Windows clipboard exists in that they are retaining the content of the source.

If you elected to cut (aka move) the cells, immediately after pasting (Ctrl+V) the cells to a new location .CutCopyMode becomes false and you lose the 'dancing border' around the source. This is because there is no content left in the source cells. The content remains accessible from the Office clipboard but is removed from the Windows clipboard.

If you elected to copy the cells, you can paste the cells to an additional location and the 'dancing border' remains. The .CutCopyMode property remains non-zero (e.g. xlCopy). You can move to another location and paste the same content; .CutCopyMode remains non-zero and the 'dancing border' around the original content persists as does the relationship to both the Office clipboard and the Windows clipboard.

If you ran VBA code that included Application.CutCopyMode = False at this point, the dancing border would disappear and the connection between any paste operation and the Office clipboard would be eliminated. This is a good state to be in when initiating a VBA sub procedure so that any potential copy/paste operation within the code could not potentially conflict with the .CutCopyMode state. However, this should only be necessary in special circumstances (see next paragraph).

Certain Excel operations are sufficient to break this Office clipboard connection and force .CutCopyMode to False. One of these is manually initiating a macro sub procedure so there is limited benefit to including Application.CutCopyMode = False at the beginning of your code. However, it may be prudent to run within your code if your code has initiated a Range.Copy operation and you have completed any Worksheet.Paste method or Range.PasteSpecial method operations with the contents of the copy.

Examining and reporting the current state of the .CutCopyMode can be done with some worksheet event macro code.

Private Sub Worksheet_SelectionChange(ByVal Target As Range)
    Select Case Application.CutCopyMode
        Case True
            Debug.Print "CutCopyMode is ON"
        Case xlCopy
            Debug.Print "CutCopyMode is in Copy mode"
        Case xlCut
            Debug.Print "CutCopyMode is in Cut mode"
        Case False
            Debug.Print "CutCopyMode is OFF"
        Case Else
            Debug.Print "???"
    End Select
End Sub

The results reported to the VBE's Immediate window will be either Copy mode, Cut mode or OFF. Application.CutCopyMode will never directly report its state as True².

While you can effect a change in the operational environment with Application.CutCopyMode = False, I have never been able to turn .CutCopyMode On by setting the property to True. No error is thrown and the official documentation specifically states that setting the property to True "Starts Cut or Copy mode and shows the moving border." but I have found that the only way to get back the 'marching ants' is to initiate another copy operation.

So for all intents and purposes, coding Application.CutCopyMode = True does no harm. However, coding Application.CutCopyMode = False can perform some good by relinquishing clipboard storage.

If anyone can turn the marching ants back on by manipulating the Application.CutCopyMode property, I would dearly love to see an example.


¹ The 'dancing border' is also known colloquially as 'marching ants'.
² While a boolean value of True or False is a distinct type, for all intents and purposes False equals zero and anything that is not False is True. If resolving boolean ► number, a VBA False is 0 and True is always equal to (-1) but if resolving the reverse number ► boolean any non-zero number is considered True and a zero is considered False.

这篇关于在退出子程序之前,我应该重新开始.CutCopyMode吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆