Hatalar, hatalar, sorular - sayfa 2239

Yeni yorum
 
Stanislav Korotky :

MSDN'yi de okudum. Açıklayın, - Microsoft İngilizce bilmiyor mu, yoksa kendi belgelerini okumuyorlar mı, yoksa - son seçenek - MQL'deki bayraklar WinApi ile benzer şekilde adlandırılıyor ancak farklı çalışıyor mu?

Buradan alınmıştır - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ - Okuma erişimi istemek için bir dosya veya cihaz üzerinde sonraki açık işlemleri etkinleştirir. Aksi takdirde, diğer işlemler okuma erişimi talep ederlerse dosyayı veya cihazı açamazlar.

FILE_SHARE_WRITE - Yazma erişimi istemek için bir dosya veya cihaz üzerinde sonraki açık işlemleri etkinleştirir. Aksi takdirde, diğer işlemler yazma erişimi talep ederlerse dosyayı veya cihazı açamazlar.

Buna dayanarak, ikinci programın okuyabilmesi için ilk programın FILE_SHARE_READ bayrağını belirtmesi yeterlidir. FILE_SHARE_WRITE, yalnızca ikinci programın dosyaya birincisine ek olarak yazacağı biliniyorsa gereklidir.

Davranıştaki farklılığa bir örnek verir misiniz?


Sağlanan bağlantıya göre, bayrakların açıklaması, aynı dosyayı birkaç kez açmaya çalışırken onları doğru bir şekilde nasıl kullanılacağı hakkında bir fikir vermiyor.

Açıklamanızdaki verilere dayanarak soruyu cevaplamaya çalışın, aşağıdaki örnekte dördüncü (hread_1) ve beşinci (hread_2) çağrılar geçerli olacak mı? 

   HANDLE hwrite     =::CreateFile(L "test.txt" , GENERIC_WRITE, FILE_SHARE_READ ,                   nullptr,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_fail =::CreateFile(L "test.txt" , GENERIC_READ, FILE_SHARE_READ ,                   nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_ok   =::CreateFile(L "test.txt" , GENERIC_READ, FILE_SHARE_WRITE ,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_1    =::CreateFile(L "test.txt" , GENERIC_READ, FILE_SHARE_WRITE ,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_2    =::CreateFile(L "test.txt" , GENERIC_READ, FILE_SHARE_WRITE | FILE_SHARE_READ ,  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

Cevabı hemen söyleyeceğim: bu aramalar geçersiz olacak

 
Stanislav Korotky :

MSDN'yi de okudum. Açıklayın, - Microsoft İngilizce bilmiyor mu, yoksa kendi belgelerini okumuyorlar mı, yoksa - son seçenek - MQL'deki bayraklar WinApi ile benzer şekilde adlandırılıyor, ancak farklı çalışıyor mu?

Buradan alınmıştır - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ - Okuma erişimi istemek için bir dosya veya cihaz üzerinde sonraki açık işlemleri etkinleştirir. Aksi takdirde, diğer işlemler okuma erişimi talep ederlerse dosyayı veya cihazı açamazlar.

FILE_SHARE_WRITE - Yazma erişimi istemek için bir dosya veya cihaz üzerinde sonraki açık işlemleri etkinleştirir. Aksi takdirde, diğer işlemler yazma erişimi talep ederlerse dosyayı veya cihazı açamazlar.

Buna dayanarak, ikinci programın okuyabilmesi için ilk programın FILE_SHARE_READ bayrağını belirtmesi yeterlidir. FILE_SHARE_WRITE, yalnızca ikinci programın dosyaya birincisine ek olarak yazacağı biliniyorsa gereklidir.

Bu flaglarda kafa karışıklığı yaşamamak için dosyayı açarak bu flagların kendimize değil diğer işlemlere okumasına ve/veya yazmasına izin verdiğimizi kesin olarak anlamanız yeterlidir.

 
Alexey Viktorov :

Bu flaglarda kafa karışıklığı yaşamamak için dosyayı açarak bu flagların kendimize değil diğer işlemlere okumasına ve/veya yazmasına izin verdiğimizi kesin olarak anlamanız yeterlidir.

İşte tam olarak bunu söylüyorum, ben MS belgelerini böyle anlıyorum (özellikle dosyayı yazmak için açan, başkalarının birlikte okumasına izin verebilir). Ve çözüm için önerilen bayrakları kullanma yöntemi bunun tam tersini önerir - paylaşılan yazma bayrağını kullanan ikinci işlem, yazılan dosyayı okumasına izin verir (yani, ilk işlemi atlıyormuş gibi, haklarını yükseltir, hatta ilk işlem yazarken paylaşım izinlerini belirtmemiş olsa da). Hatta kulağa doğal gelmiyor. Pekala, tamam, ben yorumu okuyacağım.

 
Stanislav Korotky :

İşte tam olarak bunu söylüyorum, ben MS belgelerini böyle anlıyorum (özellikle dosyayı yazmak için açan, başkalarının birlikte okumasına izin verebilir ).

Sadece okumaya değil, yazmaya da izin verebilir. Ve eğer ortak kayıt yapılacaksa, her birinde ortak kayıt yapılmasına izin verilmelidir.

Stanislav Korotki :

Ve çözüm için önerilen bayrakları kullanma yöntemi bunun tam tersini önerir - paylaşılan yazma bayrağını kullanan ikinci işlem, yazılan dosyayı okumasına izin verir (yani, ilk işlemi atlıyormuş gibi , haklarını yükseltir , hatta ilk işlem yazarken paylaşım izinlerini belirtmemiş olsa da). Hatta kulağa doğal gelmiyor. Pekala, tamam, ben yorumu okuyacağım.

Ve bu yanlış. Kendine asla hiçbir şeye izin vermez ve kendisi için hiçbir hak talep etmez. FILE_SHARE_READ ve FILE_SHARE_WRITE bayrakları , açık bir dosyanın özniteliklerine atıfta bulunur. Öznitelikler, dosyanın halihazırda işgal edildiği süreçten izin içermiyorsa, bu dosya serbest bırakılıncaya kadar kullanılmayacaktır.

Böylece, bu örneklerde ortaya çıkıyor: Birincisi, dosyayı yazmak için açtı, diğer işlemlerin okumasına izin verdi ve ikincisi, açıldığında, bu dosyayı zaten kullanan birine yazmayı yasaklamaya (izin vermemeye) çalışıyor. İşte tam burada ortalık karışıyor... Kim önce kalktıysa ve terlikler...

 
Alexey Kozitsyn :

Geliştiricilere soru.

Bir senkronizasyon işlevi vardır:

Bununla birlikte, bazen bu hatayı alıyorum:

Onlar. gösterge USDJPY üzerinde çalışıyor ve EURGBP sembolünden bir hata alıyorum. Aynı zamanda terminalde açık bir EURGBP tablosu bulunmaktadır.

Hata 4014 şunu söylüyor:

Sistem işlevinin çağrılmasına izin verilmiyor

Bu nasıl olabilir?

Ve böylece başka bir çağrı tarafından üretildi.

SymbolIsSynchronized'ı çağırmadan önce ResetLastError() kullanın

 
Slava :

Ve böylece başka bir çağrı tarafından üretildi.

SymbolIsSynchronized'ı çağırmadan önce ResetLastError() kullanın

Evet, zaten yaptım... Görünen o ki, işlevin belgelerinde bir hata olması durumunda GetLastError() öğesini çağırmanız gerektiği açıkça belirtilmiyorsa, bu, işlevin hata kodunu sıfırlamadığı anlamına gelir. Doğru?

 
Slava :

Ayrıca, prensipte hangi işlevlerin göstergede böyle bir hatanın görünmesine neden olabileceğini bilmek isterim?

 
A100 :
Benim durumumda ServiceDesk şimdi çoğalamadığını yazıyor ... buna göre salonun yardımı gerekiyor ... biraz sonra ne ve nasıl ayrıntılı olarak yazacağım

Bu nedenle, #1530548 isteğine göre, ServiceDesk şu anda bile kararlı oynatmaya sahip olmama rağmen https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 hatasını yeniden oluşturamıyor (derleme 1881'de). Biraz düşündükten sonra nedenini anladım! Cevap: çünkü yavaş bir bilgisayarım var (tablet)

Bu sorun için #1952509 numaralı talepte de benzer bir durum vardı https://www.mql5.com/en/forum/1111/page2124#comment_6518537

ServiceDesk ayrıca ilk kez hatayı yeniden oluşturamadığını bildirdi. Hatanın hala var olduğuna ikna etmek bana çok pahalıya mal oldu ... sonunda:

Destek Ekibi 2018.02.10 22:35
Görünüşe göre sorununuzu Cuma günü 39 çizelge ile zayıf bir makinede yeniden üretmişler.
izleyecek. Gerekirse, ek bilgi isteyeceğiz. Teşekkür ederim.

Bu bağlamda şu soru ortaya çıkıyor: Bu tür hatalarla hiç uğraşmaya gerek var mı ? Ya da sessizce hayatlarını yaşasınlar... belki bir daha ortaya çıkmazlar - sonuçta hızlı bir bilgisayara geçmek yeterli mi?!

Bu sorular, birkaç Uzman Danışman/Gösterge içeren bir düzine diğer grafiğin hızlı bir bilgisayarı yavaş bir bilgisayara dönüştürme konusunda oldukça yetenekli olduğu gerçeği bağlamında ortaya çıkar (ve ortalama bir tüccar sadece çok sayıda Uzman Danışman kullanır - işte bir örnek https ://www.mql5.com/en/forum/267154/page5 #comment_8164924 - 82 EA başlatıldı)... hatta başka koşullar nedeniyle (antivirüs... diğer programlar...) kısa bir süreliğine yavaşlayabilir... veya sistemin kendisi hemen hemen tüm kaynakları geçici olarak ele geçirdi).

Ve sonra tam olarak 100'de 1'lik o açıklanamaz başarısızlık gelecek (peki, doğa yasalarına göre, doğal olarak en uygunsuz zamanda gerçekleşir)

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2016.08.03
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
A100 :

Bu nedenle, #1530548 isteğine göre, ServiceDesk şu anda bile kararlı oynatmaya sahip olmama rağmen https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 hatasını yeniden oluşturamıyor (derleme 1881'de). Biraz düşündükten sonra nedenini anladım! Cevap: çünkü yavaş bir bilgisayarım var (tablet)

Bu sorun için #1952509 numaralı talepte de benzer bir durum vardı https://www.mql5.com/en/forum/1111/page2124#comment_6518537

ServiceDesk ayrıca ilk kez hatayı yeniden oluşturamadığını bildirdi. Hatanın hala var olduğuna ikna etmek bana çok pahalıya mal oldu ... sonunda:

Destek Ekibi 2018.02.10 22:35
Görünüşe göre sorununuzu Cuma günü 39 çizelge ile zayıf bir makinede yeniden üretmişler.
izleyecek. Gerekirse, ek bilgi isteyeceğiz. Teşekkür ederim.

Bu bağlamda şu soru ortaya çıkıyor: Bu tür hatalarla hiç uğraşmaya gerek var mı ? Ya da sessizce hayatlarını yaşasınlar... belki bir daha ortaya çıkmazlar - sonuçta hızlı bir bilgisayara geçmek yeterli mi?!

Bu sorular, birkaç Uzman Danışman/Gösterge içeren bir düzine diğer grafiğin hızlı bir bilgisayarı yavaş bir bilgisayara dönüştürme konusunda oldukça yetenekli olduğu gerçeği bağlamında ortaya çıkar (ve ortalama bir tüccar sadece çok sayıda Uzman Danışman kullanır - işte bir örnek https ://www.mql5.com/en/forum/267154/page5 #comment_8164924 - 82 EA başlatıldı)... hatta başka koşullar nedeniyle (antivirüs... diğer programlar...) kısa bir süreliğine yavaşlayabilir... veya sistemin kendisi hemen hemen tüm kaynakları geçici olarak ele geçirdi).

Ve sonra tam olarak 100'de 1'lik o açıklanamaz başarısızlık gelecek (peki, doğa yasalarına göre, doğal olarak en uygunsuz zamanda gerçekleşir)


Zayıf bir bilgisayarım yok. Ancak dosyayı açarken böyle bir hata da periyodik olarak ortaya çıkar.

 
Vladislav Andruschenko :
Zayıf bir bilgisayarım yok. Ancak dosyayı açarken böyle bir hata da periyodik olarak ortaya çıkar.
Üstelik sıradan bir kullanıcı değilsiniz ama birçoğunuz işinizi kullanıyor.
1...223222332234223522362237223822392240224122422243224422452246...3184
Yeni yorum