エディターで共同企画を議論しよう - なぜ、どこへ行くのか - ページ 14 1...78910111213141516 新しいコメント Vladimir Pastushak 2018.01.20 12:14 #131 何か変なプロジェクトがあるような・・・。プロジェクトにフォルダを 作ると消えてしまい、リソースにフォルダを作るとソースディレクトリに表示される・・・。プロジェクトにサブフォルダが表示されない、外部からプロジェクトにフォルダをコピーすると......。 Renat Fatkhullin 2018.01.20 12:28 #132 Vladimir Pastushak:何か変なプロジェクトがあるような・・・。プロジェクトにフォルダを 作ると消えてしまい、リソースにフォルダを作るとソースディレクトリに表示される・・・。外部からプロジェクトにフォルダをコピーしても、プロジェクトにサブフォルダが表示されないのですが...。もっと正確にパスで指定してください。例を見れば、すべてが一目瞭然です。空のフォルダーはそれ自体では機能しません。物理フォルダではなく、仮想プロジェクトの構造が表示されます。エディタがプロジェクトツリーを正しく構築するためには、フォルダにデータが含まれている必要があります。プロジェクトはほぼ完全に自動化され、無駄な手作業は一切ありません。ss: 古いやり方を引き継がず、プロジェクトワークを再編成 する必要があります。 Vladimir Pastushak 2018.01.20 13:13 #133 Renat Fatkhullin:もっと正確にパスで指定してください。一挙に例を挙げれば、すべてが明らかになる。空のフォルダーそのものは機能しません。物理フォルダではなく、仮想プロジェクトの構造が表示されます。エディタがプロジェクトツリーを正しく構築するためには、フォルダにデータが含まれている必要があります。プロジェクトはほぼ完全に自動でレンダリングされ、無駄な手作業は一切ありません。Hp: すべてがうまくいくので、古いやり方を持ち越さずに、プロジェクトに合わせて再調整 する必要があります。それが、最初に出てきたのがこちらです。コードに紐づいてもいないファイルを頑なに探す、メタを再起動しようとする Vladimir Pastushak 2018.01.20 13:18 #134 すでにプロジェクトに 絡んでいるファイルを使って、自分用のテンプレートのようなものを作ろうとしているのです。プロジェクトがなくても、やってみたら全部うまくいくんです。しかし、流行に乗り遅れないように、また、そこからプロジェクトを作るためのテンプレートを作ろうと思っても、なかなかうまくいかないのです。同時に、音の中の音楽、映像の中の映像、ヘルプの中のヘルプなど、秩序があるのも好きです。 Vladimir Pastushak 2018.01.20 13:21 #135 プロジェクトを 完全に削除することができました。 Renat Fatkhullin 2018.01.20 13:58 #136 このwavファイルがどこかに宣言されているわけですね。以前から指摘されていたプロジェクトの 問題点は見当たりません。また、プロジェクトの自動管理機能の関係上、リンク/入力ファイルが実際に存在しない状態でmqprojファイルを転送することは推奨されません。不足ファイルの情報は、プロジェクトから自動的に削除される場合があります。 Vladimir Pastushak 2018.01.20 14:20 #137 Renat Fatkhullin:このwavファイルがどこかに宣言されているわけですね。以前から指摘されていたプロジェクトの問題点は見当たりません。また、プロジェクトの自動管理機能の関係上、リンク/入力ファイルが実際に存在しない状態でmqprojファイルを転送することは推奨されません。不足ファイルの情報は、プロジェクトから自動的に削除することができます。スクリーンショットはすべてのプロジェクト ファイルを示していますが、wavはどこにも見当たりません。プロジェクト自体にこのファイルへのパスがあったので、プロジェクトを削除して問題を解決 しました...それと、もうひとつ、すべてをディレクトリに分散して、ひとつのディレクトリに複数のプロジェクトを格納した場合、ディレクトリをリネームすると、プロジェクトがコンパイルされなくなるのですが......。プロジェクトでより詳細なディレクトリ構造を検討することをお勧めします。リソースにサブフォルダを追加します。これにより、多数のリソースを持つプロジェクトでの作業が容易になります Renat Fatkhullin 2018.01.20 15:54 #138 Vladimir Pastushak: スクリーンショットにはすべてのプロジェクトファイルが写っていますが、wavはどこにも ありません。 だから、プロジェクトファイルを手動で操作（ソースデータの移動、編集、削除）する必要がない、と書いたのです。GUIでプロジェクトを操作する。それと、もうひとつ、すべてをディレクトリに分散して、複数のプロジェクトを同じディレクトリに格納した場合、ディレクトリをリネームすると、プロジェクトがコンパイルされなくなるのですが......。例を挙げてください。プロジェクトでディレクトリ名に依存している場合（ほとんどの場合そうです）、当然ながら名前を変更した後にコンパイルの問題が発生します。全てはコンパイルログに明記されています。プロジェクトでより詳細なディレクトリ構造を検討することをお勧めします。リソースにサブフォルダを追加します。これにより、リソースの数が多いプロジェクトでも簡単に作業できるようになりますサブディレクトリは（プロジェクトのどの部分でも）機能し、自動的に認識されます。ただ、もうしばらくプロジェクトで作業すれば、構造の自動化により非常に便利であることがわかると思います。手作業だけでなく、すべてがグラフィカルなインターフェースで 行われます。 Vladimir Pastushak 2018.01.20 16:43 #139 Renat Fatkhullin: だから、プロジェクトファイルに対して手動で操作（ソースデータの転送、編集、削除）しないように、と書いたのです。GUIでプロジェクトを操作する。例を挙げてください。プロジェクトでディレクトリ名に依存している場合（ほとんどの場合そうです）、当然ながら名前を変更した後にコンパイルに問題が発生します。コンパイルログには、すべてが明確に記述されています。サブディレクトリは（プロジェクトのどの部分でも）動作し、自動的に認識されます。ただ、もうしばらくプロジェクトで作業すれば、構造の自動化により非常に便利であることがわかると思います。手作業だけでなく、すべてGUIで行うことができるのです。また、疑問や問題点もあります。質の高い製品を作るために、プログラムの設定を多言語で行っています。今すぐ各言語のための独自のmqhファイルと最終的なmq5ファイルを持って、すなわち、バージョンexpert_en.mq5は、コンパイルの時にファイルの設定_en.mqhプログラムの結果として接続すると、ロシアの設定で取得されますします。 バージョンexpert_en.mq5があり、コンパイル時にsettings_en.mqhが含まれ、プログラムは英語の設定になります。現在、プロジェクトは すべて英語に限定されており、たとえインルーラー名を変更しても、コンパイル時にex5が置き換えられてしまいます。 もちろん、ディレクトリからファイルを削除してロシア語でコンパイルすることもできますが、急ぐ場合はそうもいかないことも多いでしょう...。もしかしたら、OSの言語を自動的に判別して、それに依存して設定をOSの言語に置き換える方法があるのでは？ Renat Fatkhullin 2018.01.20 16:52 #140 多言語の文字列リソースを社内で作る可能性が高いので、実行ファイルが1つで、その場で言語を変更できるようにします。実装はじっくり考えます。市場向けに多言語表記を実装する予定です。 1...78910111213141516 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
何か変なプロジェクトがあるような・・・。
プロジェクトにフォルダを 作ると消えてしまい、リソースにフォルダを作るとソースディレクトリに表示される・・・。
プロジェクトにサブフォルダが表示されない、外部からプロジェクトにフォルダをコピーすると......。
何か変なプロジェクトがあるような・・・。
プロジェクトにフォルダを 作ると消えてしまい、リソースにフォルダを作るとソースディレクトリに表示される・・・。
外部からプロジェクトにフォルダをコピーしても、プロジェクトにサブフォルダが表示されないのですが...。
もっと正確にパスで指定してください。例を見れば、すべてが一目瞭然です。
空のフォルダーはそれ自体では機能しません。物理フォルダではなく、仮想プロジェクトの構造が表示されます。エディタがプロジェクトツリーを正しく構築するためには、フォルダにデータが含まれている必要があります。
プロジェクトはほぼ完全に自動化され、無駄な手作業は一切ありません。
ss: 古いやり方を引き継がず、プロジェクトワークを再編成 する必要があります。
もっと正確にパスで指定してください。一挙に例を挙げれば、すべてが明らかになる。
空のフォルダーそのものは機能しません。物理フォルダではなく、仮想プロジェクトの構造が表示されます。エディタがプロジェクトツリーを正しく構築するためには、フォルダにデータが含まれている必要があります。
プロジェクトはほぼ完全に自動でレンダリングされ、無駄な手作業は一切ありません。
Hp: すべてがうまくいくので、古いやり方を持ち越さずに、プロジェクトに合わせて再調整 する必要があります。
それが、最初に出てきたのがこちらです。
コードに紐づいてもいないファイルを頑なに探す、メタを再起動しようとする
すでにプロジェクトに 絡んでいるファイルを使って、自分用のテンプレートのようなものを作ろうとしているのです。
プロジェクトがなくても、やってみたら全部うまくいくんです。
しかし、流行に乗り遅れないように、また、そこからプロジェクトを作るためのテンプレートを作ろうと思っても、なかなかうまくいかないのです。
同時に、音の中の音楽、映像の中の映像、ヘルプの中のヘルプなど、秩序があるのも好きです。
プロジェクトを 完全に削除することができました。
このwavファイルがどこかに宣言されているわけですね。
以前から指摘されていたプロジェクトの 問題点は見当たりません。
また、プロジェクトの自動管理機能の関係上、リンク/入力ファイルが実際に存在しない状態でmqprojファイルを転送することは推奨されません。不足ファイルの情報は、プロジェクトから自動的に削除される場合があります。
このwavファイルがどこかに宣言されているわけですね。
以前から指摘されていたプロジェクトの問題点は見当たりません。
また、プロジェクトの自動管理機能の関係上、リンク/入力ファイルが実際に存在しない状態でmqprojファイルを転送することは推奨されません。不足ファイルの情報は、プロジェクトから自動的に削除することができます。
スクリーンショットはすべてのプロジェクト ファイルを示していますが、wavはどこにも見当たりません。プロジェクト自体にこのファイルへのパスがあったので、プロジェクトを削除して問題を解決 しました...
それと、もうひとつ、すべてをディレクトリに分散して、ひとつのディレクトリに複数のプロジェクトを格納した場合、ディレクトリをリネームすると、プロジェクトがコンパイルされなくなるのですが......。
プロジェクトでより詳細なディレクトリ構造を検討することをお勧めします。リソースにサブフォルダを追加します。これにより、多数のリソースを持つプロジェクトでの作業が容易になります
スクリーンショットにはすべてのプロジェクトファイルが写っていますが、wavはどこにも ありません。
それと、もうひとつ、すべてをディレクトリに分散して、複数のプロジェクトを同じディレクトリに格納した場合、ディレクトリをリネームすると、プロジェクトがコンパイルされなくなるのですが......。
例を挙げてください。プロジェクトでディレクトリ名に依存している場合（ほとんどの場合そうです）、当然ながら名前を変更した後にコンパイルの問題が発生します。
全てはコンパイルログに明記されています。
プロジェクトでより詳細なディレクトリ構造を検討することをお勧めします。リソースにサブフォルダを追加します。これにより、リソースの数が多いプロジェクトでも簡単に作業できるようになります
サブディレクトリは（プロジェクトのどの部分でも）機能し、自動的に認識されます。
ただ、もうしばらくプロジェクトで作業すれば、構造の自動化により非常に便利であることがわかると思います。手作業だけでなく、すべてがグラフィカルなインターフェースで 行われます。
だから、プロジェクトファイルに対して手動で操作（ソースデータの転送、編集、削除）しないように、と書いたのです。GUIでプロジェクトを操作する。
例を挙げてください。プロジェクトでディレクトリ名に依存している場合（ほとんどの場合そうです）、当然ながら名前を変更した後にコンパイルに問題が発生します。
コンパイルログには、すべてが明確に記述されています。
サブディレクトリは（プロジェクトのどの部分でも）動作し、自動的に認識されます。
ただ、もうしばらくプロジェクトで作業すれば、構造の自動化により非常に便利であることがわかると思います。手作業だけでなく、すべてGUIで行うことができるのです。
また、疑問や問題点もあります。
質の高い製品を作るために、プログラムの設定を多言語で行っています。
今すぐ各言語のための独自のmqhファイルと最終的なmq5ファイルを持って、すなわち、バージョンexpert_en.mq5は、コンパイルの時にファイルの設定_en.mqhプログラムの結果として接続すると、ロシアの設定で取得されますします。
バージョンexpert_en.mq5があり、コンパイル時にsettings_en.mqhが含まれ、プログラムは英語の設定になります。
現在、プロジェクトは すべて英語に限定されており、たとえインルーラー名を変更しても、コンパイル時にex5が置き換えられてしまいます。 もちろん、ディレクトリからファイルを削除してロシア語でコンパイルすることもできますが、急ぐ場合はそうもいかないことも多いでしょう...。
もしかしたら、OSの言語を自動的に判別して、それに依存して設定をOSの言語に置き換える方法があるのでは？
多言語の文字列リソースを社内で作る可能性が高いので、実行ファイルが1つで、その場で言語を変更できるようにします。
実装はじっくり考えます。市場向けに多言語表記を実装する予定です。