2015-11-20 46 views
6

爲了優化我的代碼,我關閉了幾個Application Object member屬性;其中一個特別是.CutCopyMode property在退出我的子程序之前,我應該再次打開.CutCopyMode嗎?

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

    ' lots of code here 

我應該在別人完成之前再次將.CutCopyMode與其他人再次打開(例如True)嗎?

' lots of code here 

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

爲什麼[excel-2010]標記? – pnuts

+1

@pnuts - 除了[excel-2010]成爲我評估我所有貢獻的*事實標準*之後,我想避免與我之前未直接測試的xl2007 Office剪貼板行爲直接關聯。 – Jeeped

+0

@Jeeped我見過相當多的'Application.Calculation = xlCalculationManual''Application.Calculation = xlCalculationAutomatic'包裝,這是否有用?而在我添加公式的情況下,是否需要引發一個事件來觸發這些事件? –

回答

8

簡短的回答是,無論是Application.CutCopyMode = True做什麼都沒有或者它的什麼,你認爲它的對面。如果.CutCopyMode的當前狀態爲False,然後將其設置爲True在「跳舞邊界」不轉,如果當前狀態是xlCopy或xlCut(XlCutCopyMode Enumeration constants),設置.CutCopyMode爲True有效地將其關閉。此外,您不能將.CutCopyMode設置爲xlCopy或xlCut。

長篇小說從瞭解Application.CutCopyMode property執行的目的開始,官方文檔錯誤意味着您可以將其重新開啓。

當手動剪切(Ctrl + X)或複製(Ctrl + C)在工作表上的一個或多個細胞,所述細胞將獲得「跳舞border'¹指示操作的源。此時,.CutCopyMode非零(xlCopy或xlCut),並且存在後續粘貼操作與Office剪貼板和Windows剪貼板之間的關係,因爲它們保留源的內容。

如果選擇剪切(又名移動)的細胞,粘貼(Ctrl + V鍵)後,立即細胞到新的位置.CutCopyMode爲假,你失去了「跳舞邊框」周圍的來源。這是因爲源單元格中沒有剩餘內容。內容可從Office剪貼板訪問,但從Windows剪貼板中刪除。

如果您選擇複製的單元格,可以粘貼在細胞的其他位置和「跳舞邊界」依然存在。 .CutCopyMode屬性保持非零(例如xlCopy)。您可以移動到其他位置並粘貼相同的內容; .CutCopyMode保持非零,圍繞原始內容的「跳舞邊框」保持不變,與Office剪貼板和Windows剪貼板的關係也一樣。

如果您在此時運行了包含Application.CutCopyMode = False的VBA代碼,跳舞邊框將消失,並且任何粘貼操作與Office剪貼板之間的連接都將被消除。在啓動VBA子程序時,這是一個很好的狀態,以便代碼中的任何潛在的複製/粘貼操作都不可能與.CutCopyMode狀態發生衝突。但是,這隻在特殊情況下才有必要(見下一段)。

某些Excel的操作足以打破這一Office剪貼板連接,並迫使.CutCopyMode爲False。其中之一就是手動啓動一個宏子程序,因此在代碼的開頭加入Application.CutCopyMode = False的好處是有限的。但是,如果你的代碼已經啓動了Range.Copy操作,你已經完成了與副本內容的任何Worksheet.Paste methodRange.PasteSpecial method操作可能是審慎的代碼中運行。

檢查和報告.CutCopyMode的當前狀態,可以與一些工作表事件宏代碼來完成。

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 

報VBE的立即窗口的搜索結果將會是複印模式,剪切模式或關閉。應用。CutCopyMode不會直接將其狀態報告爲True²。

雖然您可以通過Application.CutCopyMode = False影響操作環境的更改,但我始終無法通過將屬性設置爲True來打開.CutCopyMode On。沒有錯誤拋出,官方文件明確指出將屬性設置爲True 「開始剪切或複製模式並顯示移動邊界。」但我發現回到'行軍螞蟻'的唯一方法是啓動另一個複製操作。

因此,對於所有意圖和目的,編碼Application.CutCopyMode = True沒有壞處。但是,編碼Application.CutCopyMode = False可以通過放棄剪貼板存儲來執行某些操作。

如果有人可以通過操縱Application.CutCopyMode property來改變行軍的螞蟻,我會非常喜歡看到一個例子。


¹在「跳舞邊界」也俗稱爲「行進中的螞蟻」。
²雖然布爾值True或False是不同的類型,但對於所有意圖和目的,False等於零,任何非False的值都爲True。如果解析布爾值►數字,則VBA False爲0且True總是等於(-1),但是如果解析反向數字►布爾值,則任何非零數字都被視爲True並且零被視爲False。

+0

我不知道我在等待這麼久的問題/解釋。真棒寫下來! *雙拇指* – BruceWayne

+2

我認爲這只是一個文檔錯誤。儘管可以讀取任何可能的狀態{-1,0,1,2},但只能將{0}寫入屬性。寫入屬性時,任何數值都被強制爲零。這似乎是合理的,因爲任何時候螞蟻都離開了,OCB已被擦洗。再次對這些小動物進行動畫處理會使用戶界面處於模糊狀態,表明可能粘貼,但不是,因爲OCB是空白的。這種設計是有意義的,文檔沒有。 –

+0

你有太多時間在你的手上= P我很好奇。這個收益有多少優化?需要多少個複製/粘貼以反映明顯的差異? – findwindow

相關問題