マジックナンバーの作成 - ページ 2 12345 新しいコメント gordon 2010.03.24 06:39 #11 cameofx: やれやれ、私の編集スピードに負けたか :))。編集しておきました。書き忘れました It's a GlobalVariable. そして、別のターミナルからセッションを継続する必要がある場合はどうなりますか（たとえば、コンピュータが死んだため）......？それでも永続化レイヤーは必要です（GVはターミナルと一緒に保存されます - クライアント側）。自動化された」マジックナンバーの全体的なアイデアは、各エキスパートに固有のものを取得することですが、永続化レイヤーを必要としません... cameo 2010.03.24 06:42 #12 gordon: なぜなら、そのマジックのためにパーシステンスレベルを維持しなければならないからです。ターミナルが再起動したらどうなる？魔法は違うものになる... GlobalVariableの値は最後のアクセスから14日後まで存在するとどこかで読みました。それに、もしそのテクニックが通用するならば、マジックナンバーでオーダー時刻を 取得できる利点もあります。 どうでしょうか？ cameo 2010.03.24 06:48 #13 gordon: また、別のターミナルからセッションを継続しなければならない場合はどうなるのでしょうか（たとえば、コンピュータが壊れた場合など）。その場合でも、永続化レイヤーは必要です（GVはクライアント側のターミナルに保存されます）。自動化された」マジックナンバーの全体的なアイデアは、各エキスパートに固有のものを取得することですが、永続化レイヤーを必要としません... それはおそらくGVを壊すだろうが、秒は保持され、それは 秒にユニークである IMHO.... gordon 2010.03.24 06:54 #14 cameofx: そうすると、GVは壊れるかもしれませんが、秒は持ちますし、 秒ならではのIMHOです。 それはユニークです。そこに異論はないでしょう。しかし、もう一度言いますが、コンピュータが壊れたとしましょう。Uはエキスパートを別の端末のある別のコンピュータに持って行き、同じアカウントにログインして同じエキスパートを続ける。エキスパートが適切に設計されていれば、これは問題ないはずです。ただし、この場合、エキスパートは処理する注文に別のマジックを割り当てることになります。つまり、明らかにうまくいかないのです。 gordon 2010.03.24 06:55 #15 cameofx: GlobalVariableの値は最後のアクセスから14日後まで存在するとどこかで読んだことがあります。それに、もしそのテクニックが通用するなら、マジックナンバーで注文の時間を取り出すことができるという利点もあるんだ。 どうなんでしょう？ 30だと思うのですが...。しかし、それとは関係なく、それらは特定の Terminal でクライアント側に残ります。 p.s. もしまだなら、このスレッドを見てみてください ->https://www.mql5.com/en/forum/120034. 同じ問題を議論し、多くのクールなアイデアを持っています... cameo 2010.03.24 07:33 #16 gordon: ...ただし、エキスパートが処理する注文に別の マジックを割り当てることになります。だから、明らかにうまくいかない。 よくわからないのですが... - ポイントは、生成された取引ごとに異なる マジックナンバーを割り当てることだと思ったのですが？注文がブローカーによって受理された後、OrderMagicNumber()は固定され、取得することができます。 もし、以前の'死んだ'クライアント端末による前回の取引でOrderMagicNumberが正常に生成されたなら、次の同じまたは別の端末の別の専門家は、 同じマジックナンバーを生成することはできません。 - IMHO - あなたの言葉を使えば、時間はレイヤーを必要とせずに永続的であり、2つの時間は決して同じではありません... :)) - リンクをありがとうございます。私は、完全にランダムに生成されるマジックナンバーに反対はしませんが、やはりある程度論理的で他の用途があるマジックナンバーの方が好きです...。 - 多分、この技術は、異なる端末で2つ以上の注文を 一瞬で 受け付けた 場合に壊れるの でしょう。 gordon 2010.03.24 07:55 #17 cameofx: よくわからないのですが... - ポイントは、生成された取引ごとに異なる マジックナンバーを割り当てることだと思ったのですが？注文がブローカーによって受理された後、OrderMagicNumber()は固定され、取得することができます。 もし、以前の'死んだ'クライアント端末による前の取引がOrderMagicNumberを正常に生成したなら、次の同じまたは - 異なる端末の異なる専門家は、 同じマジックナンバーを生成することはありません。 - IMHO - あなたの言葉を使えば：時間はレイヤーを必要とせずに永続的であり、2つの時間は決して同じではありません... :)) - リンクをありがとうございます。私は、完全にランダムに生成されるマジックナンバーに反対はしませんが、やはりある程度論理的で、他の用途があるマジックナンバーの方が好きです...。 - このテクニックは、異なる端末で2つ以上の注文を一瞬で 受け付けた場合に壊れるでしょう 。 いいえ、エキスパート全体が対象です。だから、同じアカウントでいくつかのエキスパートを実行する場合、彼らはお互いに干渉しません。個人的には、自動化されたシステムは好きではありませんし、使いません。私はマジックに情報を保存するため、1つのマジックナンバーではなく、各エキスパートにマジックナンバーの範囲を使用します。とはいえ、このスレッドでは、各エキスパートに 固有の マジックナンバーを自動的に 設定する方法について説明しています。 cameo 2010.03.24 08:13 #18 ゴードン 私はあなたの意見を尊重します。あまり明確に説明していなかったかもしれませんが、この技術に関する私の投稿をもう一度読んでみてください。それは、エキスパート全体に対してです。 (そのため、WindowsExpertName()呼び出しでIDを取得し、同じ名前のエキスパートが異なるチャートやTimeCurrent()に接続されるたびに、それをGlobalVariableカウンターに連結しているのです。） もう少し検討してみてください。それは保持されるか、そうでないかのどちらかです。もし、あなたや他の人が簡単に壊せると思えば、おそらく私もこれを考え直さなければならないでしょう... :)) gordon 2010.03.24 08:34 #19 cameofx: ゴードン 私はあなたの意見を尊重します。あまり明確に説明しなかったかもしれませんが、この技術に関する私の投稿をもう一度読んでください。これは、エキスパート全体を対象としたものです。 WindowsExpertName()の呼び出しと、同じ名前のエキスパートが異なるチャートに接続されるたびに、それをGlobalVariableカウンタで連結しています。 もう少し考えてみてください。この方法を使うか使わないかはあなた次第です。もし、あなたや他の人が簡単に壊せると思えば、おそらく私もこれを考え直さなければならないでしょう... :)) 私はそうしました。私はuさんが言ったこと（「生成された取引ごとに異なるマジックナンバーを割り当てることがポイントだと思った」）に言及したのであって、元の投稿に言及したのではありません。明確でなかったらごめんなさい。 とにかく、もう一度読んでみて以下は、私が見た問題点です。 - ID番号とは何でしょうか？各エキスパートにハードコードされたユニークな番号か何かですか？専門家が同じ名前を持っていないことを確認するのは簡単です、それは彼らが同じ番号を持っていないことを確認するのは難しいです、特にそれがハードコードされている場合。 - 永続性。永続性。永続性。繰り返しになりますが、別の端末からセッションを続けるにはどうしたらいいのでしょうか。例えば、タイムフレームはどこに保存されるのでしょうか？ - ユーザーはGVを手動でいじくりまわすかもしれません（しかし、ほとんどの場合、これはおそらく問題にはならないでしょう...)。 編集：タイムフレームは良い例ではないかもしれませんね。 cameo 2010.03.24 08:48 #20 私がネットに接続している時間にあなたがネットに接続しているのは嬉しいですね...:)仕事の合間を縫って... :D コードを貼っておきますね。 12345 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
やれやれ、私の編集スピードに負けたか :))。編集しておきました。書き忘れました It's a GlobalVariable.
そして、別のターミナルからセッションを継続する必要がある場合はどうなりますか（たとえば、コンピュータが死んだため）......？それでも永続化レイヤーは必要です（GVはターミナルと一緒に保存されます - クライアント側）。自動化された」マジックナンバーの全体的なアイデアは、各エキスパートに固有のものを取得することですが、永続化レイヤーを必要としません...
なぜなら、そのマジックのためにパーシステンスレベルを維持しなければならないからです。ターミナルが再起動したらどうなる？魔法は違うものになる...
GlobalVariableの値は最後のアクセスから14日後まで存在するとどこかで読みました。それに、もしそのテクニックが通用するならば、マジックナンバーでオーダー時刻を 取得できる利点もあります。
どうでしょうか？
また、別のターミナルからセッションを継続しなければならない場合はどうなるのでしょうか（たとえば、コンピュータが壊れた場合など）。その場合でも、永続化レイヤーは必要です（GVはクライアント側のターミナルに保存されます）。自動化された」マジックナンバーの全体的なアイデアは、各エキスパートに固有のものを取得することですが、永続化レイヤーを必要としません...
それはおそらくGVを壊すだろうが、秒は保持され、それは 秒にユニークである IMHO....
そうすると、GVは壊れるかもしれませんが、秒は持ちますし、 秒ならではのIMHOです。
それはユニークです。そこに異論はないでしょう。しかし、もう一度言いますが、コンピュータが壊れたとしましょう。Uはエキスパートを別の端末のある別のコンピュータに持って行き、同じアカウントにログインして同じエキスパートを続ける。エキスパートが適切に設計されていれば、これは問題ないはずです。ただし、この場合、エキスパートは処理する注文に別のマジックを割り当てることになります。つまり、明らかにうまくいかないのです。
GlobalVariableの値は最後のアクセスから14日後まで存在するとどこかで読んだことがあります。それに、もしそのテクニックが通用するなら、マジックナンバーで注文の時間を取り出すことができるという利点もあるんだ。
どうなんでしょう？
30だと思うのですが...。しかし、それとは関係なく、それらは特定の Terminal でクライアント側に残ります。
p.s. もしまだなら、このスレッドを見てみてください ->https://www.mql5.com/en/forum/120034. 同じ問題を議論し、多くのクールなアイデアを持っています...
...ただし、エキスパートが処理する注文に別の マジックを割り当てることになります。だから、明らかにうまくいかない。
よくわからないのですが...
- ポイントは、生成された取引ごとに異なる マジックナンバーを割り当てることだと思ったのですが？注文がブローカーによって受理された後、OrderMagicNumber()は固定され、取得することができます。
もし、以前の'死んだ'クライアント端末による前回の取引でOrderMagicNumberが正常に生成されたなら、次の同じまたは別の端末の別の専門家は、 同じマジックナンバーを生成することはできません。
- IMHO - あなたの言葉を使えば、時間はレイヤーを必要とせずに永続的であり、2つの時間は決して同じではありません... :))
- リンクをありがとうございます。私は、完全にランダムに生成されるマジックナンバーに反対はしませんが、やはりある程度論理的で他の用途があるマジックナンバーの方が好きです...。
- 多分、この技術は、異なる端末で2つ以上の注文を 一瞬で 受け付けた 場合に壊れるの でしょう。
よくわからないのですが...
- ポイントは、生成された取引ごとに異なる マジックナンバーを割り当てることだと思ったのですが？注文がブローカーによって受理された後、OrderMagicNumber()は固定され、取得することができます。
もし、以前の'死んだ'クライアント端末による前の取引がOrderMagicNumberを正常に生成したなら、次の同じまたは - 異なる端末の異なる専門家は、 同じマジックナンバーを生成することはありません。
- IMHO - あなたの言葉を使えば：時間はレイヤーを必要とせずに永続的であり、2つの時間は決して同じではありません... :))
- リンクをありがとうございます。私は、完全にランダムに生成されるマジックナンバーに反対はしませんが、やはりある程度論理的で、他の用途があるマジックナンバーの方が好きです...。
- このテクニックは、異なる端末で2つ以上の注文を一瞬で 受け付けた場合に壊れるでしょう 。
いいえ、エキスパート全体が対象です。だから、同じアカウントでいくつかのエキスパートを実行する場合、彼らはお互いに干渉しません。個人的には、自動化されたシステムは好きではありませんし、使いません。私はマジックに情報を保存するため、1つのマジックナンバーではなく、各エキスパートにマジックナンバーの範囲を使用します。とはいえ、このスレッドでは、各エキスパートに 固有の マジックナンバーを自動的に 設定する方法について説明しています。
私はあなたの意見を尊重します。あまり明確に説明していなかったかもしれませんが、この技術に関する私の投稿をもう一度読んでみてください。それは、エキスパート全体に対してです。
(そのため、WindowsExpertName()呼び出しでIDを取得し、同じ名前のエキスパートが異なるチャートやTimeCurrent()に接続されるたびに、それをGlobalVariableカウンターに連結しているのです。）
もう少し検討してみてください。それは保持されるか、そうでないかのどちらかです。もし、あなたや他の人が簡単に壊せると思えば、おそらく私もこれを考え直さなければならないでしょう... :))
ゴードン
私はあなたの意見を尊重します。あまり明確に説明しなかったかもしれませんが、この技術に関する私の投稿をもう一度読んでください。これは、エキスパート全体を対象としたものです。
WindowsExpertName()の呼び出しと、同じ名前のエキスパートが異なるチャートに接続されるたびに、それをGlobalVariableカウンタで連結しています。
もう少し考えてみてください。この方法を使うか使わないかはあなた次第です。もし、あなたや他の人が簡単に壊せると思えば、おそらく私もこれを考え直さなければならないでしょう... :))
とにかく、もう一度読んでみて以下は、私が見た問題点です。
- ID番号とは何でしょうか？各エキスパートにハードコードされたユニークな番号か何かですか？専門家が同じ名前を持っていないことを確認するのは簡単です、それは彼らが同じ番号を持っていないことを確認するのは難しいです、特にそれがハードコードされている場合。
- 永続性。永続性。永続性。繰り返しになりますが、別の端末からセッションを続けるにはどうしたらいいのでしょうか。例えば、タイムフレームはどこに保存されるのでしょうか？
- ユーザーはGVを手動でいじくりまわすかもしれません（しかし、ほとんどの場合、これはおそらく問題にはならないでしょう...)。
編集：タイムフレームは良い例ではないかもしれませんね。
コードを貼っておきますね。