Kütüphaneler: Takvim - sayfa 2

[Stanislav Korotky]

fxsaber:

Tüm HTML takvimlerinde ( standart olan ve Terminal dahil) üçlü (Gerçek, Tahmin, Önceki) = (Gerçek, Tahmin, Revize). Bu nedenle, bir sonraki ilgili olay gerçekleşene kadar geçmişteki Revize alanını kullanamazsınız. Diğerleri kullanılabilir.

Yerel takvim API'si ile çalışmadım - dokümantasyonu arzulanan çok şey bırakıyor (bu yüzden daha mantıklı bir kütüphane gerekli olacaktır). Belirtilen change_id'den başlayarak bir dizi olay değişikliğini sorgulamak mümkün değil mi? Bazı nedenlerden dolayı zaman tabanlı değil. Ne yazık ki, bu sorular kütüphane için değil takvimin kendisi için daha fazla, ancak kütüphane takvimin üstünde olduğu için, onun için de açık kalıyorlar. Değişikliklerle ilgili sorun şu ki, geçmişte harici takvimler kullanma pratiğimde, bazı alanların geriye dönük olarak ayarlanabileceğini fark ettim ve bu yüzden değişikliklerin kronolojisini dikkate alarak test etmemiz gerekiyor.

Önceki=revize(MqlCalendarValue yapısı 4 alana da sahiptir: gerçek, önceki, revize, tahmin) ve neden geçmişte revize kullanamadığınızı anlamıyorum - bence, revize (önceki revize ise) son olay sürümü ile bir sonraki arasında herhangi bir anda görünebilir, yani sadece geçmişte.

[fxsaber]

Stanislav Korotky:

Yerel takvim API'si ile çalışmadım - dokümantasyonu arzulanan çok şey bırakıyor (bu nedenle daha mantıklı bir kütüphane gerekli olacaktır). Belirtilen change_id'den başlayarak bir dizi olay değişikliğini sorgulamak mümkün değil mi? Bazı nedenlerden dolayı zamana bağlı değil.

Takvimdeki her değişikliğin kendi change_id'si vardır. Böylece belirli bir change_id'den geçerli change_id'ye kadar olan tüm değişiklikleri sorgulayabilirsiniz.

previous=revised(MqlCalendarValue yapısı 4 alana da sahiptir: actual, prev, revised, forecast) ve neden geçmişte revised kullanamadığınızı anlamıyorum - bence revised, son etkinlik sürümü ile bir sonraki arasında herhangi bir anda (previous revised ise) görünebilir, yani sadece geçmişte.

Takvimlerde bir etkinlik için yalnızca üç alan görebilirsiniz. API'de ise dört tane vardır. Revize edilen en son iyileştirme değeridir ve bu değer Gerçek alındıktan bir hafta sonra bile gelebilir. Geriye dönük testlerde Revize'yi kullanmanın biraz mantıklı bir şekilde yasaklanmasının nedeni budur.

Uygun takvim kullanımı senaryolarını oldukça dar görüyorum. Kendi seçenekleriniz varsa bunları dile getirin. Belki de kütüphanenin senaryolarınız için uygun olmayan bir API'si vardır. O zaman bunun hakkında düşüneceğiz.

Konu oldukça yeni gibi görünüyor.

[traveller00]

GMT işlevleri var, ancak kullanılıyor gibi görünmüyorlar. Orada gerekli olup olmadıklarını bilmiyorum.

[fxsaber]

traveller00:
GMT işlevleri var, ancak kullanılıyor gibi görünmüyorlar. Onlara ihtiyaç var mı bilmiyorum.

Gelecek için bırakıldılar. Takvim sunucu saatine bağlı olduğundan ve dışarıdan alınabildiğinden.

[Aleksey Mavrin]

fxsaber:

Ben takvimin uygun kullanım senaryolarını oldukça dar görüyorum. Kendi varyantlarınız varsa bunları dile getirin. Belki de kütüphanenin sizin senaryolarınız için uygun olmayan bir API'si vardır. O zaman bunu düşüneceğiz.

Konu oldukça yeni gibi görünüyor.

MT takvim özelliklerinin açıklamasına bakılırsa, tüm değişikliklerin izlenmesi ve abonelikle yeni etkinliklerin gelmesi ve Actual, Revised 'deki değişikliklerle Observer gibi bir şey yazmalıyız.

O zaman uygun olabileceğini düşünüyorum.

[fxsaber]

Aleksey Mavrin:

MT takvim özelliklerinin açıklamasına bakılırsa, tüm değişikliklerin izlenmesi ve aboneliğe yeni olayların gelmesi ve Actual, Revised değerlerindeki değişikliklerle birlikte Observer gibi bir şey yazmalıyız.

Terminolojik olarak anlamıyorum.

[Andrey Khatimlianskii]

fxsaber:

Terminolojik olarak, anlamıyorum.

https://refactoring.guru/ru/design-patterns/observer

[fxsaber]

Andrey Khatimlianskii:

https://refactoring.guru/ru/design-patterns/observer

Teşekkürler. OnCalendar'dan bahsediyorsak change_id mekanizması üzerinden bir çeşit simülasyon olacaktır.

Uygulama senaryolarını şematik kod ile göstermek daha doğru elbette.

[Aleksey Mavrin]

fxsaber:

Teşekkürler. OnCalendar'dan bahsediyorsak, change_id-mekanizması aracılığıyla bazı simülasyonlar olacaktır.

Gelecekte MT5'te tanıtılabilecek takvim olaylarının simülasyonundan bahsediyorsunuz.

Herhangi bir zamanda değişebileceğinden, Revize değişikliği de dahil olmak üzere, ilgilenilen olaylara abonelik mekanizmasına atıfta bulunuyordum.

Gözlemci modeline aşina değilseniz, Andrei'nin bağlantısını incelemenizi tavsiye ederim.

Fikrin özü kısaca şudur, örneğin:

Ticaret için önemi 3'ten yüksek olan tüm EUR olaylarını bilmem gerekiyor. Bir sağlayıcıya başvuruyorum ( yayıncı olarak da adlandırılan abonelikleri ve uyarıları yöneten sınıfın bir nesnesi, tek bir tane olabilir), abone oluyorum.

Ve sonra sağlayıcının kendisi ilgilendiğim olaylardaki tüm değişiklikleri izler ve beni bilgilendirir (ilgili bilgilerle olay işleme yöntemini çağırarak).

[fxsaber]

Aleksey Mavrin:

Fikrin özü kısaca şudur, örneğin:

Ticaret için 3'ten yüksek öneme sahip tüm EUR olaylarını bilmem gerekiyor. Bir sağlayıcıyla ( abonelikleri ve uyarıları yöneten sınıfın nesnesi, yayıncı olarak da adlandırılır, tek olabilir) iletişime geçiyorum, abone oluyorum.

Ve sonra sağlayıcının kendisi ilgilendiğim olaylardaki tüm değişiklikleri izler ve beni bilgilendirir (ilgili bilgilerle olay işleme yöntemini çağırarak).

Hiçbir özel nesne, ilgili bir çağrı olmadan kendini kontrol edemez. Yani kullanıcı tarafından kendi kodunda yazılmalıdır. Eğer yazmışsa, o zaman işlemi kendisi yapar.

change_id mekanizması çok basittir: Refresh yöntemini çalıştırırsınız. Bundan sonra, oluşturduğunuz olaylar listesinde neyin ve nerede güncellendiği verilerini alırsınız.

CALENDAR Calendar;

Calendar.Set(...); // İzlemek istediğiniz olayların bir listesini belirtin.

if (Calendar.Refresh(...)) // Listeden bir şey güncellenmişse, istediğiniz gibi işleyin.