Нужна ли функция по запрету печати сообщений в журнал эксперта? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
---Перечитал начало ветки, нигде не сказано, что надо печатать заранее подготовленные СТРОКИ сообщений. Если я пропустил это, приведите текст плз.
>>> "При отладке советника приходится ставить много Print'ов" - т.е. сообщения сфоримрованы в коде у ТопикСтартера. Он их печатает в Журнал.
---Задача в том, чтобы как-то отключать оператор Print, желательно средствами компилятора (это уже мое дополнение).
>>> Мы не ищем лёгких путей? )))
---1. Легкий. Строка формируется заранее. Не смысла вставлять в код дополнительные функции _Print, лучше использовать условную компиляцию.
>>> Т.е. для отключения надо лазить в Эдитор??? А пользователю через флаг в настройках не проще?
2 и 3 вообще городушка на ровном месте. Зачем так усложнять?
1. То, что "приходится ставить много Print'ов" не означает, что " т.е. сообщения сфоримрованы в коде у ТопикСтартера. Он их печатает в Журнал.".
>>> "При отладке советника приходится ставить много Print'ов"
У вас пользователи занимаются отладкой ваших программ? Бедняжки ))
Вы передергиваете факты, на этом прекращаю бессмысленное обсуждение.
а return(0); в void ? )))
искать ошибки обязанность компилятора )
покажет поправлю, нет значит всё нормально ))
если скажу что до этого OnTick(в этом примере) был int типа ты наверное в обморок упадёшь )
но это-то я поправил, а вот возврат нуля забыл )
Спасибо, Кэп )) Проблема формирования строки осталась или нет?
не было проблемы формирования строки, была проблема включения принтов во время отладки и отключения для обычной работы.
ведь вот ведь что хотел сделать ТС: "Моё предложение - сделать функции по аналогии с Print и Printf , исполнение которых будут блокироваться с помощью другой функции в коде - допустим Оffрrint."
Передайте туда только текст
А в функции только проверка НадоПечатать/НеНадоПечатать
В таком случае не придётся затирать IFы по всему телу кода, а только выключить параметр разрешения печати
теперь ифы не обязательны, теперь обязательны "_" перед Print )
Такой подход усложняет принт - вот такой код получается, если требуется не только текст, а и значение переменной получить - для чего часто и принтуется код при отладке.
bool USE_PRINT=false;
F_Print("Проверка "+DoubleToString(MAT,4));
void F_Print(string txt)
{
if(USE_PRINT==true) Print(txt);
}
Да и ifы не убирает, а они могут занять до 1% времени на вычисление, а при оптимизации это выльется в часы.
Ну и что? Осталась проблема с формированием строки.
Проголосовал Нет, так как нужна не функция, а дефайн условной компиляции, встроенный в Print на стороне разработчиков MQL.
Так сути дела оно не меняет. Такой вариант так же возможен.
А чем плоха условная компиляция-то ?
В зависимости от дебаг-дефайнов либо выводим сообщение, либо нет...
У меня в коде очень много макросов типа TRACE_DOUBLE5("Текущая цена: ",dCurPrice), которые разворачиваются либо в форматированный вывод значения в дебаг-версии, либо в пустое место в релиз-версии.
А поподробней можно, как Вы меняете способ вывода, или это опять же ифы но в другой обёртке?
Тогда уж лучше вот так
К сожалению, MQL4 позволяет задавать только 8 параметров в define, но на безрыбье и рак рыба )) Вместо неиспользуемых параметров дефайна надо что-то вставлять, например пустую строку ""
Чем такой вариант лучше самописной функции, что написана выше?
Да, все верно.
Но, этот когд был написан тогда, когда еще не было классов-темплейтов. Сейчас гляжу в их сторону, похоже, можно будет написать аналог Print(), где не надо будет указывать, какой тип у переменной.
С другой стороны - у меня есть макросы TRACE_DOUBLE, TRACE_DOUBLE4, TRACE_DOUBLE5 - которые используют различное округление double. Темплейт-классом уже будут сложности - скажем, если есть темплейты для string и double - то придется вещественный тип выводить полностью, без обрезки. А для округлений - пользоваться либо старыми макросами, либо дополнительно указывать величину округления (что, по сути, одно и то же)
По факту значит нет способа сделать самоопределение типа переменой?
не было проблемы формирования строки, была проблема включения принтов во время отладки и отключения для обычной работы.
ведь вот ведь что хотел сделать ТС: "Моё предложение - сделать функции по аналогии с Print и Printf , исполнение которых будут блокироваться с помощью другой функции в коде - допустим Оffрrint."
Alexey Volchanskiy , Andrei Fandeev не приятно, когда ссора возникает из-за заданного мной вопроса, к тому же я не понял в чём причина ярой конфронтации. От меня требуются уточнения - готов их дать - только спросите.
Цель в том, что б в идеале не усложняя код и без if'ов отключать выборочно принты, а достижение этой цели может быть разное.
Такой подход усложняет принт - вот такой код получается, если требуется не только текст, а и значение переменной получить - для чего часто и принтуется код при отладке.
bool USE_PRINT=false;
F_Print("Проверка "+DoubleToString(MAT,4));
void F_Print(string txt)
{
if(USE_PRINT==true) Print(txt);
}
Да и ifы не убирает, а они могут занять до 1% времени на вычисление, а при оптимизации это выльется в часы.
тогда делать отладку и убирать принты если после отладки они не нужны. Поиск и замена в метаэдиторе ищем Print меняем на //Print
Хорошее решение, спасибо за идею, но минус в том, что нельзя идентифицировать принты, которые нужны только для отладки. Вот если бы замена была возможна по двум строкам...
Кстати, можно просто закомментировать тело самописной функции с принтоми это будет не плохим решением!
ПредлОжу свой вариант. Он, скажем так, заходит издалека к поставленной задаче.
Есть статейка "Программируем режимы работы советника с помощью ООП" у одного писателя.
Там есть разные режимы роботов. Для каждого можно написать свой виртуальный метод Print(). Он и будет для каждого режима свой журнал печатать...
А вообще, имхо, если нужно быстро, то лучше юзать #define.