
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В общем, устал я вам объяснять. Кто хочет - тот поймёт.
Спасибо за терпение, раз это нормальное явление, то я буду это теперь знать и учитывать при анализе ошибок в своем коде. Но, хотелось бы, что б просто сбросили ошибку - одно дело, когда это не возможно, а другое дело когда, назовем особенностью вместо ошибки, так вот когда особенность объясняют сложившимися традициями.
Указывает на этот код - D.PointsFill(false);
Ошибка была в связи с разным размером массивов X и Y - почему нельзя было об этом писать в логе - загадка.
Спасибо за терпение, раз это нормальное явление, то я буду это теперь знать и учитывать при анализе ошибок в своем коде. Но, хотелось бы, что б просто сбросили ошибку - одно дело, когда это не возможно, а другое дело когда, назовем особенностью вместо ошибки, так вот когда особенность объясняют сложившимися традициями.
Запомните просто одно: в _LastError вписывается не только код реальной ошибки, но и коды сообщений о работе функций. В обсуждаемом случае - там как раз вписан код того, что нет объекта. И всё зависит от контекста, при котором запрашивается объект с определённым именем. Если для модификации объекта, то такой код укажет о необходимости понять - а почему это мой объект вдруг пропал.., а если для создания нового объекта, то код, говорящий что нет такого объекта - тут как раз наоборот - всё хорошо и можно создавать.
И примите за правило: проверять нужно результат возврата функции и, если она возвращает реальную ошибку, то уже тогда анализировать код ошибки.
Вы же в своём примере голову себе морочите тем, что было успешное создание объекта-канваса, а вы думаете, что там где-то ошибка.
Запомните просто одно: в _LastError вписывается не только код реальной ошибки, но и коды сообщений о работе функций. В обсуждаемом случае - там как раз вписан код того, что нет объекта. И всё зависит от контекста, при котором запрашивается объект с определённым именем. Если для модификации объекта, то такой код укажет о необходимости понять - а почему это мой объект вдруг пропал.., а если для создания нового объекта, то код, говорящий что нет такого объекта - тут как раз наоборот - всё хорошо и можно создавать.
И примите за правило: проверять нужно результат возврата функции и, если она возвращает реальную ошибку, то уже тогда анализировать код ошибки.
Вы же в своём примере голову себе морочите тем, что было успешное создание объекта-канваса, а вы думаете, что там где-то ошибка.
Хорошо, буду пробовать думать в описанном вами ключе при анализе ошибок. Спасибо.
Быть может Вы сможете дать ответ на мои вопросы в этой ветки, которые остались без внимания - по поводу изменения размера легенды и запрета помещения информации о созданной кривой в эту легенду?
Хорошо, буду пробовать думать в описанном вами ключе при анализе ошибок. Спасибо.
Быть может Вы сможете дать ответ на мои вопросы в этой ветки, которые остались без внимания - по поводу изменения размера легенды и запрета помещения информации о созданной кривой в эту легенду?
Не смогу - на то нужно время. Его, увы, нету, извините.
Хорошо, буду пробовать думать в описанном вами ключе при анализе ошибок. Спасибо.
Не смогу - на то нужно время. Его, увы, нету, извините.
Понял. Подожду того, кто знает или у кого есть время. Но я так понял, что штатными средствами библиотеки этого сделать нельзя.
Ошибка в CGraphic::CreateAxes:
Вместо выделенного должно быть m_y.Color() и m_x.Color(), соответственно.
Решается наследованием от CGraphic и переопределением CreateAxes (благо, виртуальный).
В том же CGraphic::CreateAxes используется m_grid.clr_frame, который невозможно задать самостоятельно:
Необходимо добавить метод для установки значения:
Почему не рисуется горизонтальная линия на графике? Почему у неё координаты типа int, а не double?