MQL4 ve MQL5 ile ilgili herhangi bir acemi sorusu, algoritmalar ve kodlar hakkında yardım ve tartışma - sayfa 520
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Böyle bir tasarımda yanlış olan nedir?
Yoksa tarih saatini yayınlamak daha mı iyi? uzun yazmak için?
Ancak doğruluğu artırma eğilimi açıktır (hafifçe söylemek gerekirse datetime, time_t'den büyüktür)
ve bunun yerine, süreleri karşılaştırmak için bu kadar uzun süre verilmelidir. Derleyici bir şeyi optimize ederse, onu atar ve gelecek için depozito kalır :-)
şimdiye kadar herhangi bir sorun görmüyorum.
Ancak doğruluğu artırma eğilimi açıktır (hafifçe söylemek gerekirse datetime, time_t'den büyüktür)
ve bunun yerine, süreleri karşılaştırmak için bu kadar uzun süre verilmelidir. Derleyici bir şeyi optimize ederse, onu atar ve gelecek için depozito kalır :-)
Sonuç olmadan değişmeden kullanmanın mümkün olduğu anlamına mı geliyor?
Sonuç olmadan değişmeden kullanmanın mümkün olduğu anlamına mı geliyor?
Peki, sonuçları olmadan nasıl :-)
uzun x için = TimeCurrent() ; Zaten iyi bir şirkette "yüze çarpıyor" :-) Sadece fizikteki tipler farklı değil, aynı zamanda farklı boyutlardalar ve daha büyük bir boyutu daha küçük bir boyuta getiriyorsunuz.
aksi takdirde, evet, (datetime)TimeCurrent tarihinden itibaren tüm saniyeler uzun süreye yerleştirilmiş gibi görünüyor
harika bir işlev var StringFind() - "#" veya hemen "#" dizesinin oluşumunu arayın
ve onunla ne yapmalı?
StringSubstr 'da her şey açıktır, hemen sayıları aldık - bir bilet, ancak burada StringFind'de , yorumda "to #" olduğunu zaten biliyoruz
Bulundu
ve onunla ne yapmalı?
StringSubstr 'da her şey açıktır, hemen sayıları aldık - bir bilet, ancak burada StringFind'de , yorumda "to #" olduğunu zaten biliyoruz
ama nerede olduğunu bilmiyoruz :-) StringFind - istenen "#" nin tam olarak bu konumdan olduğunu söyleyecektir. ya da hiç değil. Asla ağdan gelene güvenmeyin ve kişisel olarak / kişisel olarak kontrol etmiyorsunuz :-) Burada para oynuyoruz - burada her şey ciddi
ama nerede olduğunu bilmiyoruz :-) StringFind - istenen "#" nin tam olarak bu konumdan olduğunu söyleyecektir. ya da hiç değil. Asla ağdan gelene güvenmeyin ve kişisel olarak / kişisel olarak kontrol etmiyorsunuz :-) Burada para oynuyoruz - burada her şey ciddi
yorumdan bileti seçip "#'a" atmanız gerekiyor.
açık pozisyonun biletini kapalı pozisyonun yorumunda bulunan biletle karşılaştırmanız gerekir.
neden "#" için arıyoruz?
StringSubstr işlevi, yorumun istenen bölümünü döndürür. Bu fonksiyon neden kapalı bir pozisyonun değil de açık pozisyonun karını döndürüyor? MODE_HISTORY içinde sıralıyorum
Böyle bir tasarımda yanlış olan nedir?
Yoksa tarih saatini yayınlamak daha mı iyi? uzun yazmak için?
yorumdan bileti seçip "#'a" atmanız gerekiyor.
açık pozisyonun biletini kapalı pozisyonun yorumunda bulunan biletle karşılaştırmanız gerekir.
neden "#" için arıyoruz?
Yorumda "to# veya dan# var mı" anlamak için arıyoruz. Değilse, bu emir kapalı pozisyonun bir parçası değildir ve buna ihtiyacımız yoktur.
StringFind(OrderComment(),"#to") sıfırdan büyük veya sıfıra eşitse, yorum gerekli alt diziyi içerir ve ancak şimdi bu satırdaki bilet numarasının konumunu hesaplamak mümkündür.
StringSubstr işlevi, yorumun istenen bölümünü döndürür. Bu fonksiyon neden kapalı bir pozisyonun değil de açık pozisyonun karını döndürüyor? MODE_HISTORY içinde sıralıyorum
Ve bu sorunun cevabı bu.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
MQL4, yardım ve algoritmalar ve kodlar hakkında herhangi bir acemi sorusu
2018.04.07 00:25
Bulunduve onunla ne yapmalı?
StringSubstr 'da her şey açıktır, hemen sayıları aldık - bir bilet, ancak burada StringFind'de , yorumda "to #" olduğunu zaten biliyoruz
Ama yapmazsanız, beklediğiniz şeyi elde edemezsiniz.