Выражения PowerBuilder на элементах управления столбцами странное поведение - PullRequest
3 голосов
/ 30 декабря 2011

Я работаю над устаревшим приложением PowerBuilder, мы обновили до PowerBuilder 12, но продолжаем использовать «классическую» IDE.

У меня есть сетка DataWindow, совместно использующая данные DataWindow произвольной формы, оба наследуют предкикоторые гарантируют, что при изменении текущей строки в сетке произвольная форма прокручивается до той же строки.

Я начал использовать выражения в свойствах Protect и Background.Color элементов управления столбца в свободной форме для имитации включения / отключения, в качестве альтернативы использованию DataWindow.Modify для rowfocuslined.

Пока что мне понравился этот подход, он выглядит намного чище, и нет очевидного снижения производительности, так как я не обращаюсь к базе данных ни в одном из моих выражений.

Проблема заключается в том, что по причинам, из-за которых мне сложно определить, эти выражения иногда приводят к сбою вышеупомянутой функциональности синхронизации строк.

В моем тестовом сценарии есть двастроки в сетке.Выбор строки 2 не заставляет произвольную форму прокручиваться до строки 2, несмотря на то, что отладка показывает, что ScrollToRow действительно вызывается нормально.Затем я снова выбираю строку 1, не могу быть уверен, работает ли это или нет, поскольку произвольная форма никогда не покидала строку 1 для начала.Затем я выбираю строку 2 второй раз, и произвольная форма прокручивается до строки 2 должным образом, и впредь все становится просто замечательно.

Я однажды исправил эту проблему в другом окне, перемещая код внутри одного конкретного выражения, нетПонять, почему это сработало, изменения не повлияли на результат выражения.К сожалению, мне не так легко исправить это в моем текущем окне.До сих пор я мог решить эту проблему с потерей функциональности, удалив выражение Protect из одного конкретного столбца EditTask DateTime или установив положительное значение TabOrder предыдущего столбца EditTask DateTime.Первый столбец нуждается в выражении Protect, а второй столбец должен быть недоступным для редактирования.Я попытался дать второй столбец положительный TabOrder при установке его выражения Protect в 1, но это не сработало.

Я рву волосы и ненавижу PowerBuilder что-то жестокое!Я был бы признателен, если бы кто-нибудь имел представление о том, в чем заключается проблема и как я могу продолжать использовать преимущества выражений столбцов, избегая их.Я не хочу возвращаться к манипулированию этим материалом с помощью Modify from rowfocuschanged.

Ответы [ 2 ]

2 голосов
/ 03 января 2012

Вот ответ в ретроспективе, взяв и добавив к тому, что было разработано в комментариях.

Когда вы устанавливаете новую строку, PowerBuilder пытается установить для столбца тот же столбец, который в данный момент имеет фокус в текущей строке. В базовом случае это прекрасно работает, но когда атрибут Protect имеет выражение, все может быть немного менее предсказуемо. Я не уверен, существует ли задокументированное или предполагаемое поведение в случае, когда столбец в строке назначения защищен, но моя позиция безопасности заключается в том, что поведение непредсказуемо, и вы, вероятно, просто не должны этого делать. Как доказал Майк, явная установка столбца решает его проблему.

Другая основная вещь, которую нужно проверить, если вы пытаетесь решить подобную проблему, это убедиться, что RowFocusChanging не возвращает 1, чтобы предотвратить изменение строки.

Удачи,

Терри.

1 голос
/ 04 января 2012

У меня возникла похожая проблема, при которой не только поля защищаются, но и цвет фона и текста изменяются при изменении фокуса строки.

По некоторым причинам выражения Datawindow довольно противоречивы, особенно когда есть другие стили, такие как флажки. Удаление всех этих выражений из объекта datawindow и помещение их всех в одно пользовательское событие / функцию в элементе управления datawindow, который вызывается из события rowfocuschanged () списка сетки с помощью Post (), похоже, помогает. Кроме того, этот способ даст вам больший контроль над тем, когда действительно запускаются события, в отличие от наличия кода в выражениях dw.

...