Farklı terminallerde çalışan iki Uzman Danışman arasında veri alışverişi - sayfa 3

Yeni yorum
 

Еще можно попробовать забить гвоздь лампочкой. У некоторых получается.

Ve böyle bir yaklaşımın çarpıklığı nedir?

Ayrıca sistem saatini de ayarlayabilirsiniz.

Böylece sistem saatine göre senkronizasyon gider :-). Kurulum yoluyla değil, okuma yoluyla. Böyle bir veri alışverişi .

 

Herkese iyi günler!

Terminallerin güvenilir şekilde bağlanmasının en iyi yollarından biri, 1C ağının kullanılmasıdır.
İki ana olasılık:
1. ana uygulama 1C'de çalışır, terminaller ve MQL4 programları yürütücüdür,
2. Ana uygulama terminallerden birinde çalışıyor, 1C uygulaması bağlayıcı protokol olarak kullanılıyor.

Avantajlar:
1. Farklı sunuculardan alınan tekliflerin tam geçmişini aynı anda saklama ve işleme yeteneği;
2. Broker raporlarını uzlaştırma olasılığı ile işlemlerin tam muhasebe kayıtlarını tutma yeteneği.

Samimi olarak,
Ais

 
Andres >> :

Bu yüzden zaten küçük bir kitaplık yazdım ve danışmanlarım zaten kayıt defteri aracılığıyla tamamen değişiyor. Aslında, RAM üzerinden değişiyorlar, diske herhangi bir okuma-yazma gözlemlemiyorum.


Sağlanan kütüphane için teşekkürler! Ben de bu takas uygulamasıyla ilgileneceğim.

Hemen açık bir soru var. Parametre okuma/yazma kontrolünü nasıl uyguluyorsunuz? Yani, başka bir danışman bazı anahtar parametrelerin zaten okunabileceğini nasıl anlar?

Başka bir EA tarafından bir tür ek okuma/yazma izin anahtarı mı oluşturuyorsunuz, yoksa test ettiğiniz başka bir olasılık var mı? Başka bir deyişle, herhangi bir parametreye üniter erişim sağlanarak, Uzman Danışmanların arızaları önlemek için aynı anahtar parametre ile aynı anda çalışmaması nasıl sağlanır?

 

Anahtar parametreye nasıl birleşik erişim sağladığını anladım. GetErrorString(int ErrorCode) işlevi aracılığıyla hataları kontrol etmeniz yeterlidir.

Ve bir hata durumunda, muhtemelen ikinci bir işlem yapın. Doğru, bu tekrarlanan işlemin yapıldığı kütüphaneden anlamadım. Muhtemelen, zaten sizin için gerekli olanı eklemek gerekli olacaktır. Her durumda, güzel çözüm için teşekkürler!

 

Bu, Win API üzerinde, yalnızca anahtarların dize parametreleriyle çalışmanıza izin veren, hata çıktılı basit bir sarmalayıcıdır.

GetErrorString( int ErrorCode ), hataların ne zaman meydana geldiğini bilmek için oldukça gösterge niteliğindedir: ne, nerede, neden ve nasıl düzeltilir. Elbette, meydana gelen hataların işlenmesini sarmalayıcı-kütüphane işlevlerinin dışına taşımak ve bunlara farklı şekillerde tepki vermek (birçok hata türü vardır), zaten anahtarları çeşitli yöntemlerle kullanma mantığına dayalı olarak mümkündür ve hatta gereklidir. uzmanlar. Bu arada, herhangi bir başarısız denemede SetStringValue() size yalnızca denemenin başarısız olduğunu söyleyebilir. Ve GetStringValue(), başarısızlık durumunda sadece söylemekle kalmaz, aynı zamanda boş bir dize döndürür. İşletim sistemi bu tür kontrolleri yaptığı için ek bir okuma/yazma izin anahtarına gerek olmadığını düşünüyorum. Hataları ele almak ve bunlara doğru şekilde yanıt vermek yeterlidir. "Sıcak" test için Uzman Danışmanlarım, zaman içinde senkronize değiller, bu yüzden muhtemelen aynı alanı aynı anda okurken/yazarken çakışmalar yaşamadılar. Ama elbette bu bir çözüm değil. Devam etmemiz gerekiyor. Yine de bir gecede yazdım, kesin hüküm vermeyin. Yöntemi hissetmek için bir "beta" versiyonu gibi :-).

 
Andres >> :

Bu yüzden zaten küçük bir kitaplık yazdım ve danışmanlarım zaten kayıt defteri aracılığıyla tamamen değişiyor. Aslında, RAM üzerinden değişiyorlar, diske herhangi bir okuma-yazma gözlemlemiyorum. MSDN, kayıt defterine birkaç yüz KB'den fazla veri göndermemenin daha iyi olduğunu söylüyor.

Kitaplık, tüm anahtarlar ve parametreler geçici kayıt defteri alanında oluşturulacak ve kalıcı kayıt defterine yazmayacak şekilde yapılandırılır. Yeniden başlatmanın ardından bu anahtarlar artık orada değil.

Bir AMA - kitaplık yalnızca 255 karakterden uzun olmayan (MQL'de sınır) dize parametreleriyle çalışır. Ama bu yeterli. Genel olarak, kayıt defterindeki parametreler farklı türlerde olabilir ve sadece dizeler değil, bence şu ana kadar başka türlere ihtiyaç yoktur. Şimdi kayıt defteri aracılığıyla iki Uzman Danışmanı değiştiriyorum, ancak daha fazlası mümkün :-). Başka bir artı, Win API'sinde ağ kayıt defterine bağlanmanın mümkün olmasıdır. Aynı ağda farklı makinelerde çalışan Expert Advisor'lar arasında bilgi alışverişi yapmak isteyen varsa bu yöne bakabilirsiniz. Bence - hızlı, basit ve güvenilir ve herhangi bir dll ve dosya olmadan. Bir hat sürdü - bir hat aldı.

Andrey, teşekkürler!

Kendim için biraz düzenledim ve süsledim.

Bunu kumbarana koyabilir misin? Çok iyi bir karar!

Dosyalar:
reglib.rar  11 kb
 

Bir gün Andrey, grafik değişkenlerle çalışmak için kitaplığımı kitaplığımla bütünleştireceğim. Başka bir değişken bildirimi düzeyi alın.

1. Global Süper Değişken olacaktır . Böyle bir değişken işletim sistemi düzeyinde görünür olacaktır.

2. Artık bir GlobalVariable var.

3. Ve GlobalChartVariable global grafik değişkenleri vardır. Yalnızca bir pencerenin programları tarafından görülebilirler.

Genel olarak, MQL4'te işletim sistemi düzeyinde kendi yapılarınızla çalışmak için bir kitaplık edinmelisiniz.

 
Zhunko >> :

1. Global Süper Değişken olacaktır . Böyle bir değişken işletim sistemi düzeyinde görünür olacaktır.

Kod tabanına böyle bir değişken koyarsanız çok minnettar olurum (ve muhtemelen tek kişi ben değilim).

Zanaat yöntemleri kullanmaktan zaten bıktım.

 

Andrey'e soru. Burada kayıt aktaracak?

 string GetStringValue1 ( int    hKey ,      // Код ключа реестра.
                        int    lpSize ,    // Длина считываемой строки.
                        string ValueName ) // Имя параметра ключа.
 {
  int lpType [ 1 ] ;      // Возвращаемый тип параметра.
  int lpcbData [ 1 ] ;    // Размер буфера.
  int i ;              // Переменная для подрезки последних пустых строк.
  int lres ;           // Результат.
  string lpData = "" ; // Буфер для возвращаемой строки.
  //----
  lpcbData [ 0 ] = lpSize ; // Размер буфера.
  for ( i = 0 ; i < lpSize ; i + + ) lpData = lpData + "#" ;
  lres = RegQueryValueExA ( hKey , ValueName , 0 , lpType , lpData , lpcbData ) ; // вызов API
  // Теперь в lpcbData[0] размер скопированных байт. Проверяем результат.
  if ( lres ! = ERROR_SUCCESS )
   {
    Print ( "Error in RegQueryValueExA(): " , GetErrorString ( lres ) ) ;
    return ( "" ) ;
   }
  if ( lpType [ 0 ] = = REG_SZ | | lpType [ 0 ] = = REG_EXPAND_SZ ) return ( StringSubstr ( lpData , 0 , lpcbData [ 0 ] - 1 ) ) ;
  return ( "" ) ;
 }
  
Açıklayacağım. Gerçek şu ki, arabellek olarak dinamik olarak büyüyen bir dize kullanırsanız, bazı hatalar gözlemlenecektir. Buna daha önce rastladım: 
InitRegDefines();
hKey = CreateKey( HKEY_CURRENT_USER, "!MT4TestKey" );

// заносим
SetStringValue( hKey, "Param", "Test" );

// вытаскиваем при помощи Вашей функции:
Print( GetStringValue1( hKey, 20, "Param" ) );

Bundan sonra ortaya çıkıyor:

2009.05.19 01:22:16 2008.12.31 01:49 geçici EURUSD,M1: ####
2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1: RegCreateKeyExA(): Var olmayan bir bölüm oluşturuldu.
2009.05.19 01:22:16 sıcaklık test için başladı

Yani, arama sırasında herhangi bir hata oluşmamasına rağmen arabelleğin içeriği değişmez. Ve kayıt defteri tam olarak "Test" dizesini içeriyor

Forum gönderilerinden bunun, dizelerin MQL ortamından DLL işlevlerine olağandışı geçişinden kaynaklandığını anladım. MQL ortamında, geliştiriciler kendi yöneticilerini (dize havuzu) kullanarak dizeler üzerinde çalışırlar ve görünüşe göre bu sınırda yanlış arabellek dolduruluyor ve bu nedenle API işlevi tarafından döndürülen sonucu göremiyoruz. Ancak, tam maksimum uzunlukta başlatılan dizeleri kullanırsanız, bildiğim kadarıyla sorun olmaz. Bu yüzden 255 karakterden oluşan bir "#" satırı var. Çizgiyi gözle görünür kılmak için "#" sembolü seçildi. Çağrıdan önce arabelleğin nasıl doldurulduğu önemli olmadığından, bunun Win API'sinin kendisiyle ilgisi yoktur. Bu, daha önce bahsettiğim hattın uzunluğundaki sınırlamadır. 255 karakterden büyük dizeleri SetStringValue() öğesine iletebilirsiniz, ancak bunları okuyamazsınız.

Tabii ki, kısıtlama olmadığında iyidir, ancak çok fazla rahatsızlık görmüyorum. Soru ortaya çıkıyor: neden belirli bir boyutta bir dize okumanız gerekiyor? Bu bir sınırlamaysa, kayıt defterine yazıldığında kaynak dizeyi 255 + "artık" parametre uzunluğunda N parametresine bölen bir işlev yazılarak da atlanabilir. Ve okurken - geri toplanır. Başka yolu yok gibi. Zor bulursan, benimle iletişime geç - yapacağım. Sadece herkesin ihtiyaçları farklıdır, her şeyi öngöremezsiniz, sadece bu benim için yeterli ve birileri global değişkenleri ve hatta birkaç düzeyde kullanıyor.

12345678
Yeni yorum