2012-08-09 105 views
1

我正在調用所提到的函數,它正確地遍歷所有匹配。但是,在處理完所有匹配的塊後,它不會完成執行。我可能會做錯什麼?NSRegularExpression enumerateMatchesInString:[...] usingBlock不會停止

的使用正則表達式爲:/\[([^\[\{,]*(,\n)?)*\]/

+0

你確定這是你的正則表達式?對我來說似乎不正確。 – FailedDev 2012-08-09 19:11:40

+1

它被格式化爲一個Objective-C字符串。 – 2012-08-10 09:20:44

+0

我已將它修復爲正常的正則表達式格式 – 2012-08-10 09:21:34

回答

4

從你的回答自己的問題來看,似乎你通過傳遞NSMatchingReportCompletion解決了這個問題。我懷疑你可能治癒了症狀而不是疾病。

我不知道你可能不小心傳遞了錯誤的options價值enumerateMatchesInString。例如,它很容易讓人誤調用它像這樣:

[regex enumerateMatchesInString:stringToSearch 
         options:NSRegularExpressionCaseInsensitive 
          range:NSMakeRange(0, [stringToSearch length]) 
        usingBlock:^(NSTextCheckingResult *result, NSMatchingFlags flags, BOOL *stop) { 
         // This is called many times, 
         // even when there is no match! 
        }]; 

這乍一看,看起來不錯,編譯器不抱怨,但我們得到的塊的不良行爲獲取調用的次數太多,通常與result == nil

您可以通過將NSMatchingReportCompletion添加到options來解決此問題,而不是多次調用該塊,它只會在匹配時調用,並在完成後再次調用。這解決了它,但這是一個不合理的解決方案,並忽略了問題的根源。

問題是NSRegularExpressionCaseInsensitive根本不是爲enumerateMatchesInStringoptions參數的適當的值......這是爲regularExpressionWithPatternoptions值)。更糟糕的是,NSRegularExpressionCaseInsensitive恰好與NSMatchingReportProgress相同,這會產生您描述的行爲。

正確的解決辦法是簡單地傳遞的0options值,如下圖所示,並enumerateMatchesInString將被稱爲只是爲了比賽,而不是臨時的進步,而不是完成時:

[regex enumerateMatchesInString:stringToSearch 
         options:0 
          range:NSMakeRange(0, [stringToSearch length]) 
        usingBlock:^(NSTextCheckingResult *result, NSMatchingFlags flags, BOOL *stop) { 
         // do stuff here 
        }]; 
+1

oops。你是對的。我的錯。 – 2013-12-04 15:56:40

0

我已經通過傳遞NSMatchingReportCompletion作爲選項,並在與之匹配的是零設定停止YES修復了這個問題。