Дистрибутив Viper теперь доступен на FTP Галактики!
По адресу ftp://ftp.galaktika.ru/pub/support/gala ... 810/VIPER/
По мере выпуска новых версий, файлы в этой папке будут регулярно обновляться.
Пользователям, которые приобрели лицензию «VIP – компилятор пользовательских интерфейсов», рекомендуем использовать в повседневной работе среду разработки Viper (взамен строчного компилятора и редактора Support).
Viper
Re: Viper
Добрый день.
Помогите, пожалуйста, с такой проблемой.
Пытаюсь отладить интерфейс Z_PayRep::FPayRoll (файл исходника FPayRoll.vip). Ставлю точку останова в процедуре HeaderFooterFile. Запускаю интерфейс в Галактике. VipER открывает файл PAFilter.vpp, после чего Галактика закрывается, и процесс отладки прекращается. VipER версии 5.4.37.0 (на новом ещё не пробовал, так как Галактика ещё на 37-м Атлантисе). Никакие логи в директории EXE VipER-а не формируются.
Убираю точку останова - интерфейс работает нормально.
Что можно сделать?
Помогите, пожалуйста, с такой проблемой.
Пытаюсь отладить интерфейс Z_PayRep::FPayRoll (файл исходника FPayRoll.vip). Ставлю точку останова в процедуре HeaderFooterFile. Запускаю интерфейс в Галактике. VipER открывает файл PAFilter.vpp, после чего Галактика закрывается, и процесс отладки прекращается. VipER версии 5.4.37.0 (на новом ещё не пробовал, так как Галактика ещё на 37-м Атлантисе). Никакие логи в директории EXE VipER-а не формируются.
Убираю точку останова - интерфейс работает нормально.
Что можно сделать?
Re: Viper
Добрый день.
Есть у кого-нибудь какие-то рекомендации по решению проблемы из предыдущего сообщения? Сейчас отладка в VipER у меня отсутствует полностью - любое использование точек останова валит Галактику без логов. Переустановка VipER не помогла. Куда можно копать?
Есть у кого-нибудь какие-то рекомендации по решению проблемы из предыдущего сообщения? Сейчас отладка в VipER у меня отсутствует полностью - любое использование точек останова валит Галактику без логов. Переустановка VipER не помогла. Куда можно копать?
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Re: Viper
Kefiro писал(а):Добрый день.
Помогите, пожалуйста, с такой проблемой.
Пытаюсь отладить интерфейс Z_PayRep::FPayRoll (файл исходника FPayRoll.vip). Ставлю точку останова в процедуре HeaderFooterFile. Запускаю интерфейс в Галактике. VipER открывает файл PAFilter.vpp, после чего Галактика закрывается, и процесс отладки прекращается. VipER версии 5.4.37.0 (на новом ещё не пробовал, так как Галактика ещё на 37-м Атлантисе). Никакие логи в директории EXE VipER-а не формируются.
Убираю точку останова - интерфейс работает нормально.
Что можно сделать?
1) Попробуйте из окна Выражения и переменные убрать все выражения
2) Попробуйте закрыть окно просмотра локальных переменных.
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Re: Viper
Еще, если не поможет, и сделай пожалуйста дополнительный тест:
1) На рабочем месте, где воспроизводится проблема запустить Viper с ключом -logtofile
Пример : Viper.exe -logtofile
2) Выполнить действия, приводящие к ошибкам.
3) В момент работы приложения будут сформированы файлы 'ViperLog.sil' и возможно 'ViperLogCompile.sil', 'ViperError.log', 'AtlError.log'
4) После завершения теста закрыть Viper либо отключить диагностику клавишей [Alt+Shift+F4]
5) Полученные файлы, вместе с описанием проблемы, отправить по адресу viper@galaktika.by для анализа.
Re: Viper
Миша, спасибо. Помогла очистка окна Выражения и переменные.
А это из-за каких-то особенных выражений? Или сложно сказать? Я заметил, что у меня там присутствовали выражения, использующие функции из wt.dll. Может, в них причина была? Собственно, эти функции работают, когда изначально проведена специальная инициализация, а в моём отлаживаемом коде, такой инициализации не было (эти выражения остались от другой отладки). Без инициализации эти функции, судя по коду, возвращают всякие нули...
А это из-за каких-то особенных выражений? Или сложно сказать? Я заметил, что у меня там присутствовали выражения, использующие функции из wt.dll. Может, в них причина была? Собственно, эти функции работают, когда изначально проведена специальная инициализация, а в моём отлаживаемом коде, такой инициализации не было (эти выражения остались от другой отладки). Без инициализации эти функции, судя по коду, возвращают всякие нули...
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Re: Viper
Да, в этой и в других DLL есть масса функций которые без дополнительной инициализации просто выдают Runtime Error.Kefiro писал(а):Миша, спасибо. Помогла очистка окна Выражения и переменные.
А это из-за каких-то особенных выражений? Или сложно сказать? Я заметил, что у меня там присутствовали выражения, использующие функции из wt.dll. Может, в них причина была? Собственно, эти функции работают, когда изначально проведена специальная инициализация, а в моём отлаживаемом коде, такой инициализации не было (эти выражения остались от другой отладки). Без инициализации эти функции, судя по коду, возвращают всякие нули...
К стати на подобные грабли можно также случайно наткнуться если в редакторе в момент отладки навести мышкой на их упоминание или на переменную с похожим именем. В момент расчета их значения при выдаче хинта, отлаживаемое приложение окажется не готовым для расчета и упадет :)
Re: Viper
Добрый день.
Прошу учесть пожелания по развитию VipER.
Возможно, я где-то повторюсь. Может быть, что-то уже реализовано, может быть, в процессе работы. Я не знаю, насколько это всё можно сделать, но если есть заинтересованность в данных предложениях, то можно обсуждать, что тут действительно нужно, что нужно в первую очередь, как это сделать.
Вообще говоря, хочется иметь среду, которая умеет не просто редактировать текст, компилировать и отлаживать. Поэтому предлагаем реализовать три таких предложения. Потребуется, очевидно, большая доработка для этого.
1. Код на випе часто (даже как правило) содержит описание визуальных элементов. Рассмотрите, пожалуйста, возможность реализации дизайнера, который умел бы генерировать нужный код после того, как программист специальным образом нарисует, как должно выглядеть окно. То есть предполагается некий набор прототипов визуальных элементов: окон-контейнеров, кнопок, полей ввода, колонок и т.д. Программист, пользуясь этими прототипами, размечает окно, располагает элементы в окне, задаёт их свойства, связывает с переменными, указывает константы событий, возникающих в данных виджетах, для дальнейшей обработки этих событий и т.д. Упомянутые в дизайнере события могли бы автоматически быть добавлены в конструкцию handleEvent.
2. Хотелось бы иметь автоматический фоновый контроль вводимого кода в редакторе. Другими словами, нужен какой-то предкомпиляционный обработчик текста, который умел бы контролировать корректность кода. Понятно, что нельзя проконтролировать всё, но как минимум можно проследить отсутствие или несоответствие парных скобок и парных конструкций, явно лишние отдельные символы или запрещённые языком символы в идентификаторах. В окне Структура кода иногда можно понять, что где-то не хватает слова end, но не ясно, где именно. Скобки иногда тоже обрабатываются. Например, закрывающая скобка метода исключает этот метод из списка, но это совершенно не помогает контролю, потому что совсем не очевидно, что есть ошибка. Но такая обработка проводится далеко не во всех случаях.
Можно отследить типы переменных и определить по подключённому заголовочному файлу, что у такой-то переменной-ссылки неверно указан вызов метода или обращение к свойству. Заведомо неверный текст лучше помечать в редакторе, а не в окне структуры кода.
Кроме того, хотелось бы иметь возможность автоматического дописывания имени локальных переменных и полей интерфейса по нажатию горячей клавиши. В качестве развития можно предложить сделать также автоподсказки: редактор мог бы предлагать выбор имён локальных переменных, членов объектов, на которые ссылается вводимая переменная, и полей физических таблиц.
Зачастую приходится тратить уйму времени на обнаружение опечаток. Надо каждый раз запускать компиляцию, исправлять опечатку в слове или опущенную скобку, потом повторять сначала.
В дополнение, было бы удобно иметь возможность открыть файл, в котором объявлен/определён метод или свойство, на котором стоит курсор, и спозиционироваться в этом файле на выбранный член. То же касается любого ссылочного типа: нажал программист на кнопку (или выбрал из локального меню редактора), когда курсор находится на идентификаторе типа, – открывается файл, в котором этот тип объявлен или реализован.
3. Возможность автосоздания кода в файлах по шаблонам. Речь идёт не о тех шаблонах стандартных конструкций, которые реализованы. Речь о ОО-возможностях випа. Хотелось бы уметь создать интерфейс, указав начальные данные в мастере: имя интерфейса и объектного интерфейса, имена файлов самого интерфейса и заголовочного (которые по умолчанию совпадают с именами интерфейсов), имена базовых интерфейсов и имена объектных интерфейсов, которые реализуются. Мастер мог бы создать нужные файлы и заготовки кода в этих файлах. Кроме этого, хочется иметь возможность после объявления методов и свойств в заголовочных файлах по нажатию кнопки перенести все эти объявления в файл, где эти члены реализуются. Было бы хорошо, если бы после ввода слов implements … редактор сам бы потребовал добавления нужных членов в код самого инерфейса и, по согласию программиста, сделал бы это. Если в мастере указано, что данные интерфейс реализует какой-то объектный интерфейс, то мастер мог бы автоматически добавить в заготовку имена реализуемых членов.
Желание такое возникает из-за того, что приходится заниматься копипастом для определения объявленных методов и свойств. Часто приходится эти члены дублировать в потомках и в заголовочных файлах потомков (когда, например, методы переопределяются в расширяющих интерфейсах).
Кстати, может быть, было бы удобно в окне проекта иметь возможность представления структуры проекта с группировкой файлов по расширению vip и vih.
Несколько слов об отладке.
Лично для меня процесс отладки представляется правильным в таком виде. Отладчик останавливает выполнение на той строке, которая помечена точкой останова, если выполняются условия, описанные для этой точки. В процессе отладки исходный файл надо открывать только в том случае, если:
- на него ссылается точка останова,
- программист нажал Трассировку на методе, который определён в этом файле,
- программист нажал Просмотр на методе или свойстве, реализованном в файле (это вообще-то касается редактора как такового, а не отладчика).
Во всех остальных случаях (хотя какие-то случаи могу упустить из виду) нет надобности открывать файл. Сейчас отладить интерфейс, особенно штатный, сложно из-за того, что отладчик пытается открыть кучу файлов исходников, которые программисту не нужны совсем, он не их хочет отлаживать. Если этих исходников нет, что как правило случается, то программисту приходится заниматься беседой с системой на тему ненайденных файлов, нажимая на кнопки в предупреждающих сообщениях.
Кроме того почему-то выбор между Трассировкой и Шагом не всегда приводит к ожидаемым результатам – иногда Трассировка просто выполняет функцию и переходи на другую строку, не задерживаясь на самой функции, то Шаг делает всё наоборот. Особенно часто путаница возникает с вызовом методов другого интерфейса. Чётко понять, от чего это зависит, мне пока не удалось. Мне кажется, что тут должен работать такой принцип. Если в строке присутствует вызов прикладной функции или процедуры, то Трассировка должна перейти в эту функцию и остановить выполнение на первой строке. Если файл с кодом не найден, то предупредить об этом в соответствии с настройкой системы, где, например, можно было бы отключить это предупреждение. Если в строке несколько вызовов, то начинать надо с первого, потом возвращаться из функции на строку вызова, чтобы можно было также зайти в следующую вызываемую функцию. А Шаг должен выполнить код строки и перейти на следующую.
Вообще говоря, останов выполнения должен произойти только тогда, когда процесс доходит до точки останова (с выполнением условий), либо как результат действий Трассировка, Шаг и Выполнить до курсора. Кстати, было бы удобно в этот перечень команд добавить команду выхода из метода или локальной функции, т.е. выполнить функцию до конца, вернуться в строку вызова и остановиться.
Есть в VipER окно, которое называется Интерфейсы. Мне не совсем понятно, для чего нужны функции этого окна в отношении работы отладчика. У моего коллеги есть мнение, что было бы удобно перед отладкой определить перечень отлаживаемых интерфейсов, как это делается для встроенного галактического отладчика. На мой взгляд, это какой-то лишний функционал, даже несмотря на то, что мне, так или иначе, не удалось определить такой перечень (отладчик почему-то игнорирует все мои манипуляции со списком интерфейсов в этом окне). Может быть, он заточен под какие-то действия, которые я никогда не выполняю… Считаю, что достаточно поставить точку останова на нужной строке кода, и это будет являться признаком начала отладки. Для чего ещё помечать интерфейс для этого? Может быть, чтобы можно было чужие интерфейсы отлаживать? Но в любом случае, если нет исходного файла, ни о какой отладке речи быть не может. А если есть – то всегда можно управиться точками останова.
Напоследок прошу добавить подсветку ключевых слов absolute и inherited.
Прошу учесть пожелания по развитию VipER.
Возможно, я где-то повторюсь. Может быть, что-то уже реализовано, может быть, в процессе работы. Я не знаю, насколько это всё можно сделать, но если есть заинтересованность в данных предложениях, то можно обсуждать, что тут действительно нужно, что нужно в первую очередь, как это сделать.
Вообще говоря, хочется иметь среду, которая умеет не просто редактировать текст, компилировать и отлаживать. Поэтому предлагаем реализовать три таких предложения. Потребуется, очевидно, большая доработка для этого.
1. Код на випе часто (даже как правило) содержит описание визуальных элементов. Рассмотрите, пожалуйста, возможность реализации дизайнера, который умел бы генерировать нужный код после того, как программист специальным образом нарисует, как должно выглядеть окно. То есть предполагается некий набор прототипов визуальных элементов: окон-контейнеров, кнопок, полей ввода, колонок и т.д. Программист, пользуясь этими прототипами, размечает окно, располагает элементы в окне, задаёт их свойства, связывает с переменными, указывает константы событий, возникающих в данных виджетах, для дальнейшей обработки этих событий и т.д. Упомянутые в дизайнере события могли бы автоматически быть добавлены в конструкцию handleEvent.
2. Хотелось бы иметь автоматический фоновый контроль вводимого кода в редакторе. Другими словами, нужен какой-то предкомпиляционный обработчик текста, который умел бы контролировать корректность кода. Понятно, что нельзя проконтролировать всё, но как минимум можно проследить отсутствие или несоответствие парных скобок и парных конструкций, явно лишние отдельные символы или запрещённые языком символы в идентификаторах. В окне Структура кода иногда можно понять, что где-то не хватает слова end, но не ясно, где именно. Скобки иногда тоже обрабатываются. Например, закрывающая скобка метода исключает этот метод из списка, но это совершенно не помогает контролю, потому что совсем не очевидно, что есть ошибка. Но такая обработка проводится далеко не во всех случаях.
Можно отследить типы переменных и определить по подключённому заголовочному файлу, что у такой-то переменной-ссылки неверно указан вызов метода или обращение к свойству. Заведомо неверный текст лучше помечать в редакторе, а не в окне структуры кода.
Кроме того, хотелось бы иметь возможность автоматического дописывания имени локальных переменных и полей интерфейса по нажатию горячей клавиши. В качестве развития можно предложить сделать также автоподсказки: редактор мог бы предлагать выбор имён локальных переменных, членов объектов, на которые ссылается вводимая переменная, и полей физических таблиц.
Зачастую приходится тратить уйму времени на обнаружение опечаток. Надо каждый раз запускать компиляцию, исправлять опечатку в слове или опущенную скобку, потом повторять сначала.
В дополнение, было бы удобно иметь возможность открыть файл, в котором объявлен/определён метод или свойство, на котором стоит курсор, и спозиционироваться в этом файле на выбранный член. То же касается любого ссылочного типа: нажал программист на кнопку (или выбрал из локального меню редактора), когда курсор находится на идентификаторе типа, – открывается файл, в котором этот тип объявлен или реализован.
3. Возможность автосоздания кода в файлах по шаблонам. Речь идёт не о тех шаблонах стандартных конструкций, которые реализованы. Речь о ОО-возможностях випа. Хотелось бы уметь создать интерфейс, указав начальные данные в мастере: имя интерфейса и объектного интерфейса, имена файлов самого интерфейса и заголовочного (которые по умолчанию совпадают с именами интерфейсов), имена базовых интерфейсов и имена объектных интерфейсов, которые реализуются. Мастер мог бы создать нужные файлы и заготовки кода в этих файлах. Кроме этого, хочется иметь возможность после объявления методов и свойств в заголовочных файлах по нажатию кнопки перенести все эти объявления в файл, где эти члены реализуются. Было бы хорошо, если бы после ввода слов implements … редактор сам бы потребовал добавления нужных членов в код самого инерфейса и, по согласию программиста, сделал бы это. Если в мастере указано, что данные интерфейс реализует какой-то объектный интерфейс, то мастер мог бы автоматически добавить в заготовку имена реализуемых членов.
Желание такое возникает из-за того, что приходится заниматься копипастом для определения объявленных методов и свойств. Часто приходится эти члены дублировать в потомках и в заголовочных файлах потомков (когда, например, методы переопределяются в расширяющих интерфейсах).
Кстати, может быть, было бы удобно в окне проекта иметь возможность представления структуры проекта с группировкой файлов по расширению vip и vih.
Несколько слов об отладке.
Лично для меня процесс отладки представляется правильным в таком виде. Отладчик останавливает выполнение на той строке, которая помечена точкой останова, если выполняются условия, описанные для этой точки. В процессе отладки исходный файл надо открывать только в том случае, если:
- на него ссылается точка останова,
- программист нажал Трассировку на методе, который определён в этом файле,
- программист нажал Просмотр на методе или свойстве, реализованном в файле (это вообще-то касается редактора как такового, а не отладчика).
Во всех остальных случаях (хотя какие-то случаи могу упустить из виду) нет надобности открывать файл. Сейчас отладить интерфейс, особенно штатный, сложно из-за того, что отладчик пытается открыть кучу файлов исходников, которые программисту не нужны совсем, он не их хочет отлаживать. Если этих исходников нет, что как правило случается, то программисту приходится заниматься беседой с системой на тему ненайденных файлов, нажимая на кнопки в предупреждающих сообщениях.
Кроме того почему-то выбор между Трассировкой и Шагом не всегда приводит к ожидаемым результатам – иногда Трассировка просто выполняет функцию и переходи на другую строку, не задерживаясь на самой функции, то Шаг делает всё наоборот. Особенно часто путаница возникает с вызовом методов другого интерфейса. Чётко понять, от чего это зависит, мне пока не удалось. Мне кажется, что тут должен работать такой принцип. Если в строке присутствует вызов прикладной функции или процедуры, то Трассировка должна перейти в эту функцию и остановить выполнение на первой строке. Если файл с кодом не найден, то предупредить об этом в соответствии с настройкой системы, где, например, можно было бы отключить это предупреждение. Если в строке несколько вызовов, то начинать надо с первого, потом возвращаться из функции на строку вызова, чтобы можно было также зайти в следующую вызываемую функцию. А Шаг должен выполнить код строки и перейти на следующую.
Вообще говоря, останов выполнения должен произойти только тогда, когда процесс доходит до точки останова (с выполнением условий), либо как результат действий Трассировка, Шаг и Выполнить до курсора. Кстати, было бы удобно в этот перечень команд добавить команду выхода из метода или локальной функции, т.е. выполнить функцию до конца, вернуться в строку вызова и остановиться.
Есть в VipER окно, которое называется Интерфейсы. Мне не совсем понятно, для чего нужны функции этого окна в отношении работы отладчика. У моего коллеги есть мнение, что было бы удобно перед отладкой определить перечень отлаживаемых интерфейсов, как это делается для встроенного галактического отладчика. На мой взгляд, это какой-то лишний функционал, даже несмотря на то, что мне, так или иначе, не удалось определить такой перечень (отладчик почему-то игнорирует все мои манипуляции со списком интерфейсов в этом окне). Может быть, он заточен под какие-то действия, которые я никогда не выполняю… Считаю, что достаточно поставить точку останова на нужной строке кода, и это будет являться признаком начала отладки. Для чего ещё помечать интерфейс для этого? Может быть, чтобы можно было чужие интерфейсы отлаживать? Но в любом случае, если нет исходного файла, ни о какой отладке речи быть не может. А если есть – то всегда можно управиться точками останова.
Напоследок прошу добавить подсветку ключевых слов absolute и inherited.
-
masygreen
- партнер
- Сообщения: 112
- Зарегистрирован: Чт, 20/03/2008 09:10
- Имя Фамилия: Максим Черепанов
- Откуда: IT
- Контактная информация:
Re: Viper
из совсем простого .. добавьте номер версии в заголовок.. а то у меня их 4 штуки каждый раз думаю чем же я собираю ....
из более сложного .. какой нибудь вариант папок дайте уже в дереве файлов...
из более сложного .. какой нибудь вариант папок дайте уже в дереве файлов...
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Re: Viper
будет в следующей версииmasygreen писал(а):из совсем простого .. добавьте номер версии в заголовок.. а то у меня их 4 штуки каждый раз думаю чем же я собираю ....
есть функция "файловый проводник", она вам помогает?masygreen писал(а):из более сложного .. какой нибудь вариант папок дайте уже в дереве файлов...
-
masygreen
- партнер
- Сообщения: 112
- Зарегистрирован: Чт, 20/03/2008 09:10
- Имя Фамилия: Максим Черепанов
- Откуда: IT
- Контактная информация:
Re: Viper
.. имеется в виду в дереве проекта... как-то смотреть от корня не очень интересно, хотя если бы можно было сделать корнем папку проекта ..larin писал(а):есть функция "файловый проводник", она вам помогает?masygreen писал(а):из более сложного .. какой нибудь вариант папок дайте уже в дереве файлов...
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Семинар - Новые возможности компиляции и отладки в Viper
5 января 2012 г. в Минском офисе корпорации Галактика прошел обзорный семинар для разработчиков. Новые возможности компиляции и отладки в Viper. Посетители форума могут также посмотреть видео с этого семинара на YouTube.
[youtube=640,480]http://www.youtube.com/watch?v=RcSYnKe8cZE[/youtube]
В добавок ссылка для загрузки и просмотра в offline.
[youtube=640,480]http://www.youtube.com/watch?v=RcSYnKe8cZE[/youtube]
В добавок ссылка для загрузки и просмотра в offline.
-
larin
- топ-софт
- Сообщения: 228
- Зарегистрирован: Пн, 10/09/2007 12:13
- Имя Фамилия: Михаил Ларин
- Откуда: ТопCофт
- Контактная информация:
Re: Viper
Опций на этот счет никаких нет. Возможно речь идет о разных сообщениях. Покопался в кодах компилятора нашел выдачу сообщений в трех местах.vlade писал(а):первый день на вайпере, не пинайте:
на випе несовпадение структуры формы и прототипа воспринимается как предупреждение а здесь как ошибка
где это настраивается?
Похоже что сообщение с текстом:
Код: Выделить всё
'Несовпадение структуры формы прототипа "%s" и присоединенной формы "%s"' А два сообщения с текстом:
Код: Выделить всё
'Несовпадение структуры присоединенной формы "%s" из ресурса "%s"'
'Несовпадение контрольной суммы присоединенной формы "%s" из ресурса "%s"' Выдаются они немного в разных ситуациях. Укажите точный текст сообщения.
Хотя по сути, при несовпадении структуры присоединенных форм, с высокой долей вероятности они просто не будут корректно работать. Вам все собственные присоединенные формы обязательно нужно синхронизировать с текущими обновлениями Галактики.