在 MQL5/MQL4 中重點(diǎn)對象的保護(hù)

如果沒有這種保護(hù), 對程序創(chuàng)建對象屬性的訪問就會更加開放.

我來向您解釋一下我的意思. 為了保護(hù)對象, 防止它們被刪除或者修改屬性 - 名稱, 描述, 顏色等等. 提供了一個OBJPROP_HIDDEN特性, 可以被明確使用. 它可以設(shè)置障礙, 使得圖形對象的名稱在終端的對象列表菜單中不顯示: 圖表 -> 對象 -> 對象列表. 默認(rèn)情況下, 顯示日歷事件的對象, 交易歷史和MQL5程序所創(chuàng)建的對象都設(shè)置了這一選項(xiàng) .

明確設(shè)置禁止(沒有默認(rèn)設(shè)置) 可以在代碼中如下實(shí)現(xiàn):

ObjectSetInteger(chart_id,name,OBJPROP_HIDDEN,true);

其中:

• ObjectSetInteger 是用于設(shè)置對象相關(guān)屬性數(shù)值的函數(shù);

• chart_id 標(biāo)示出放置對象的圖表(當(dāng)前圖表為0);

• name 是應(yīng)用此函數(shù)的對象的名稱;

• true 與OBJPROP_HIDDEN一起調(diào)用會在對象列表中隱藏此對象(false取消隱藏).

這種實(shí)現(xiàn)方式以及相關(guān)代碼可以在文檔中找到. 通過點(diǎn)擊提供的對象類型列表中的任意鏈接, 您就可以看到使用函數(shù)創(chuàng)建對象的例子代碼.

在圖形對象名稱列表中禁止顯示的對象, 不論是明確說明還是默認(rèn)的, 都可以通過按下全部按鈕來顯示圖表上的全部對象來看到. 對于通過對象列表人工干預(yù)圖形對象的屬性來說這只是初級保護(hù).

編輯切換為居中

圖 2. 在按下"全部"按鈕之前的圖表上的對象列表

編輯切換為居中

圖 3. 在按下"全部"按鈕之后的圖表上的對象列表

事實(shí)上, 圖形對象就算您讓它不可見, 它在圖表上也無法完全隱藏, 這是一個優(yōu)點(diǎn)而不是缺點(diǎn). 您可以在列表中快速瀏覽, 修改或者復(fù)制對象的屬性, 而不需要檢查整個圖表, 因?yàn)閳D表中甚至可能包含前些年的對象和柱形. 另外, 列表中的對象可以根據(jù)類型, 名稱和其他一些參數(shù)進(jìn)行排序.

MetaTrader 5和MetaTrader 4交易終端的眾多優(yōu)點(diǎn)之一就是可以自己簡單地開發(fā)自動化交易程序, 也可以使用其他人開發(fā)的多個應(yīng)用. 但是人們會永遠(yuǎn)都不犯錯嗎?另外, 寫程序的準(zhǔn)備水平也可能是不一樣的. 也有內(nèi)在的倫理邊界. 編程語言就和人一樣, 隨著時間也能改變和提高.

所以, 如果您能夠在程序創(chuàng)建圖形時就保證正確, 絕對是件好事. 您可以在列表中快速找到需要的對象并看到它們的屬性, 而不是在整個圖表上尋找它們. 另外, 您可以確保圖表中不含有任何錯誤或者故意隱藏的對象, 包括程序代碼中錯誤生成的對象.

通過在列表中顯示全部對象, 然后選擇其中的一些進(jìn)行刪除, 也有可能意外刪除控制面板中當(dāng)時還需要的對象.

在繼續(xù)程序的回應(yīng)操作之前, 我們可以利用前文中提到的MQL5和MQL4語言的優(yōu)點(diǎn). 我是指能夠在代碼中使用不同的方法來完成不同的任務(wù).

3. 創(chuàng)建對象的策略

如有必要, 這將有助您在代碼中創(chuàng)建您自己的解決方案, 而不是浪費(fèi)時間在尋找方案中走上錯誤或者復(fù)雜的道路.

為了防止聽起來過于正式和專業(yè), 我將告訴您我是怎樣找到這種策略的. 之后提到的代碼附加在文章的末尾. 為了它們能夠運(yùn)行您需要把代碼庫中的包含文件ObjectCreateAndSet, 保存到您客戶終端的Include文件夾中. 它包含了用于創(chuàng)建對象和通過必要的檢查來修改它們屬性的函數(shù). 這個文件在附加的test_types_of_chart_events指標(biāo)的運(yùn)行中并不需要.

3.1. 在實(shí)際寫代碼之前的考量和操作

根據(jù)文檔, 您可以使用OnChartEvent()函數(shù), 在圖表上有變化或用戶事件的時候, 為了您任務(wù)的目標(biāo), 獲得和處理大約9種類型的事件. 它們中的一些是通知關(guān)于圖形對象的刪除, 修改和創(chuàng)建的.

首先, 我是想如何在代碼中實(shí)現(xiàn)如下功能:

• 如果對象被人工或者程序刪除或修改了, 它們可以"自我恢復(fù)";

• 在有這樣的外部操作時程序可以從圖表上"自我分離".

這兩種功能都需要同時實(shí)現(xiàn)圖表上因?yàn)槟橙嘶蛘叱绦蛑孛淖兂?#34;外來者"的對象, 并且不能有更多循環(huán)的事件處理.

我的第一個思路是在整個程序中當(dāng)收到有關(guān)對象被修改或者刪除的事件時, 來自我檢測其屬性的變化, 但是這看起來不是最好和最實(shí)用的方法. 然后我想到, 完全自我檢測可能意味著有許多不必要的操作.

例如, 在對象行為的事件處理中, 圖表對象的名稱在程序中都會進(jìn)行比較和跟蹤. 當(dāng)在程序中跟蹤任意類型的事件時, 我們的得到的不僅是圖形對象的信息, 而是圖表上的全部對象. 對象名稱的類型是string(字符串), 而 string 類型數(shù)據(jù)的處理時間比其他類型要長. 圖表上可能有很多人工創(chuàng)建或者其他程序創(chuàng)建的對象, 其中可能會進(jìn)行各種操作, 這樣會產(chǎn)生大量的事件.

以下是一個類似的代碼框架, 在啟用了圖表對象刪事件通知的情況下, 會進(jìn)行檢測對象名稱的匹配比較. 代碼中沒有進(jìn)行預(yù)先處理以減少比較的次數(shù), 它應(yīng)用于多個圖形對象的處理中:

if(id==CHARTEVENT_OBJECT_DELETE) ? ? ? ?{ ? ? ? ? string deletedChartObject=sparam; ? ? ? ? //--- ? ? ? ? for(int i=QUANT_OBJ-1;i>=0;i--) ? ? ? ? ? { ? ? ? ? ? ?if(StringCompare(deletedChartObject,nameObj[i],true)==0) ? ? ? ? ? ? ?{ ? ? ? ? ? ?/*這里有一些代碼, 如果 ? ? ? ? ? ?事件中主題的名稱和 ? ? ? ? ? ?程序中對象的名稱完全匹配的話, 會進(jìn)行相應(yīng)處理.*/ ? ? ? ? ? ? ? return; ? ? ? ? ? ? ?} ? ? ? ? ? } ? ? ? ?}