Об окнах в Аксапте

[Lazy_Tiger]

Господа, это только у меня или у всех окна аксапты ведут себя "разумно"? В том смысле что если я максимизирую окно и выбираю в нем из выпадающем списке комбобокса нечто, то окно нормализуется?

Кто нить может мне подсказать - ЗАЧЕМ? И самое главное - как избавится? такое поведение имеет место быть аж с версии 2.1 (более ранних не видел) и до сих пор не исправлено.

[Роман Кошелев]

Lazy_Tiger,
У меня окна Аксапты ведут себя также неадекватно. Это раздражает.

Кроме того, в Аксапте:
- не реализованы модальные диалоги - не используются dockable-окна.
В таком интерфейсе, как в Аксапте, эти недостатки критичны.
При том, что подобные вещи есть и в MFC, на котором, по слухам, строится Аксапта, и в Стингрее, да и полно где ещё...

Тем не менее, это, видимо так и останется без внимания -- судя по всему, принято решение делать весь интерфейс web-ориентированным, т.е. обращаться теперь к аксапте будем через браузер.

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

[Buh]

Гопода!
У меня в Аксапте не сохраняются размеры окна, ширина столбцов и их порядок. Не говорю уж о скроллерах, которые как хотят, так и меняют свою ширину и положение. Поэтому присоединяюсь: "Кто нить может мне подсказать - ЗАЧЕМ? И самое главное - как избавится?".
Скажите, зачем так сделали и как избавиться?

[Lazy_Tiger]

А что говорит по этому поводу Навижн и Коламбус в частности? все мои запросы такого плана туда уходят в "никуда". Ну в смысле вообще не отвечают. Еще имея версию 2.1 я обращался с этими вопросами, "а воз и ныне там". хотя вообщем то вроде как в _некоторых_ местах исправлено, но еще больше мест осталось

кроме того, у меня есть списочек действий, выполнение которых приводит к немедленному и безусловному прибиванию аксапты Dr. Watson'ом. Например нажатие кнопочки "отправить по почте..." в любой из форм где таковая кнопка есть. реакция Навижн и Коламбуса - аналогичная.

Я не совсем понимаю в этом контексте, а за что мы все бабки неслабые за "техсуппорт" платим?

[Pavel]

Привет,

Точно не могу ответить на вопрос по сохранению настроек форм, т.к. в демоверсии нет доступа к средствам разработки. Но могу сделать предположение. На поведение окна влияет специальный параметр в свойствах формы. Он, скорее всего, установлен в значении «Фиксированное» (или что-то вроде) и после изменения формы пользователем при выходе возвращает ее в исходное состояние. В XAL 3.1 это именно так.

Успехов.

[Maxim Gorbunov]

Цитата:

На поведение окна влияет специальный параметр в свойствах формы. Он, скорее всего, установлен в значении «Фиксированное» (или что-то вроде) и после изменения формы пользователем при выходе возвращает ее в исходное состояние.

Совершенно верно. У каждой формы (окна), а точнее у ее дизайна, в Axapta есть свойство SaveSize. Если Вам настолько принципиально сохранение размеров окна при закрывании, установите его значение в Yes.

Думаю, что что-то подобное есть и для столбцов. Если же такого нет, то это совсем несложно запрограммировать (да простит меня mazzy, не переносящий излишков программирования в Axapta).

С модальными диалогами не все так гладко. Справедливости ради стоит заметить, что часть окон в Axapta все-таки появляются как модальные (сообщения о некоторых ошибках, например). Думаю, что это может являться надеждой на скорое нахождение пути решения этой проблемы.

Цитата:

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

К сожалению, мне Ваш опыт повторить не удалось. Все работает как-будто нормально (проверял в форме "Номенклатурные единицы"). Другой связанной проблемой является то, что в случае закрытия максимизированного окна, окно, в которое переходит фокус ввода также максимизируется. Это неудобно, но что поделать. Вообще, Axapta реализует некое подобие виртуального десктопа. Десктоп Axapta больше размеров экрана, и перемещаться по нему можно с помощью автоматически появляющихся Scroll Bar'ов. В этой ситуации максимизированными окнами вообще пользоваться не рекомендуется, так как становится размытой семантика максимизации окна (не понятно, до каких размеров окно увеличивать: размеров экрана или виртуального десктопа).

Цитата:

Не говорю уж о скроллерах, которые как хотят, так и меняют свою ширину и положение... Кто нить может мне подсказать - ЗАЧЕМ?...

Подсказываю. Дело в том, что Axapta ориентирована на технологию тонкого клиента, то есть каждому рабочему месту сервер передает лишь необходимый минимум информации, чтобы как можно меньше загружать канал связи (в частности; на самом деле, конечно, не только для этого). Описываемое Вами поведение скроллеров имеет место в списках, состоящих из записей таблиц базы данных. Размеры этих таблиц (а значит и размеры списков) не входят в необходимый для работы минимум, а поэтому информация о них постоянно уточняется (по мере получения новых записей). При уточнении размеров происходит изменение представления Scrolling'а.

[Buh]

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

[mazzy]

Цитата:

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

На самом деле это очень типичное желание.
И типичная проблема для клиент-серверных приложений.

Дело в том, что передать то можно.
Но до того как передать, надо вычислить количество записей в таблице.
А это потенциально очень долгая операция. Причем долгая не для Аксапты, а для SQL сервера. Время выполнения этой команды можно визуально оценить. Меню сервис \ Разработка \ Количество записей.

Сейчас в качестве общего количества записей указывают то количество, которое попало в кэш.

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

[Роман Кошелев]

1. Не очень верится, чтобы такая простая операция занимала много времени.
2. Можно ли где-нибудь в настройках увеличить размер кеша?

[Buh]

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

[mazzy]

К Роман Кошелев:
"Не очень верится, чтобы такая простая операция занимала много времени".

Насколько я понимаю, выполняется
select count(recid) from table

это далеко не простая операция.
А насчет времени все же посмотри как открывается форма, которая показывает количество записей.

Размер кэша не решит эту проблему


К Buh:
"а можно создать таблицу, в которой будет содержаться длина необходимых списков, тогда обращаться можно к ней и не заниматься подсчетом записей."

Во-первых не списков, а таблиц. Они по разному хранятся.
Во-вторых. Это ж сетевая версия!
Предположим, что один раз посчитали, другой пользователь добавил несколько (или сотню) записей. Что тогда будет с бегунком у первого пользователя?

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


Говорю же, это не Аксаптовская проблема.
Это пролема большинства клиент-серверных приложений.

Если вспомнить тот же 1С.
SQL версия 1Са просто держит бегунок постоянного размера в центре скроллера.

Если вспомнить Навижин, то там вообще нет бегунка.

Если вспомнить Конкорд... Блин, не помню как это было в Конкорде... По-моему его вообще не было. Может Pavel подскажет?

В Аккпаке тоже бегунок по хитрому устроен.

В четвертом Сане бегунок работает как в Аксапте. В Пятом Сане бегунка вроде вообще нет, насколько я помню. Завтра надо у наших уточнить.

В САПе вроде тоже бегунка нет.

[Роман Кошелев]

Вполне допустимо и понятно что в 1С это сложно сделать -- у них там всё левой рукой через правое ухо достаётся (метамодель данных).

А вот в Аксапте, где метамодель практически напрямую отображается в SQL, узнать число строк несложно. Конечно, "select count(recId) from table" будет выполняться медленно, но, с другой стороны, "а зачем?".
Сергей (buh) угудал -- в SQL есть такие мета-таблицы. Более того, необходимость в них указана Тэдом Коддом в его "Двенадцати правилах, которым должна соответствовать реляционная СУБД".
http://matviyko.narod.ru/transaction.htm (см. "Реляционная БД")

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

Место, в котором хранится необходимая информация, называется "системные таблицы". Там есть все -- от описания столбцов таблиц до привелегий (прав), индексов и взаимосвязей. Вряд-ли там нет числа строк в таблицах.

Например, в том же MS SQL Analyzer видим саму таблицу LedgerJournalTrans и её описание. И там, и там -- 810 строк.


Системная таблица SysIndexes


Собственно таблица LedgerJournalTrans

[Maxim Gorbunov]

...а как, на мой взгляд, верно заметил Сергей (mazzy), в том, что Axapta - программа сетевая. Как вы будете решать проблему, когда таблицу одновременно несколько пользователей редактируют? Во-первых, даже если размеры бегунка будут постоянно актуальны, им все равно придется динамически меняться. Во-вторых, чтобы эту актуальность поддерживать, придется постоянно запрашивать данные "системной таблицы". К чему это приведет? Не знаю, но канал связи уж точно не разгрузит.

Предвижу вопрос: почему бы не считать данные из этой таблицы хотя бы один раз перед началом использования таблицы.

Объясняю свое мнение. Заметьте, что когда Вы перетаскиваете бегунок (не нажимаете на стрелки, а именно перетаскиваете), информация в связанном с ним списке обновляется динамически (то есть соответствует положению бегунка). Если бегунок будет знать длину таблицы (сейчас он знает только длину кэша), то при отборажении записей, не внесенных в кэш, потребуются обмены с БД, что замедлит процесс перетаскивания бегунка, а это не соответствует стандартам качества Microsoft (операции, требующие удержания клавиши мыши, должны выполняться как можно быстрее, чтобы не заствалять пользователя жать на кнопку дольше, чем нужно).

Обратите внимание, что сейчас, когда вы перетаскиваете бегунок, список обновляется мгновенно. Подумайте, готовы ли вы заплатить за актуальность размеров бегунка увеличением времени обновления списка.

[Роман Кошелев]

Одни ищут способы "как сделать", другие -- оправдание "почему не делать"
Есть масса подходов удовлетворить и пользователей и канал. Как <u>пример</u> (!) такая концепция:

1. Если пользователь тащит бегунок, чтобы наблюдать ползущие данные, то он будет готов к тому, чтобы:
а. Эти данные будут поставляться ему медленно
б. Эти данные будут даваться ему через 1-2-3, и т.д. строки. Пока он не остановится. Тогда окно можно полностью заполнить. Пропущенные данные можно отображать так: Извините | эта строка не успела | загрузиться

2. Если пользователь тащит бегунок, чтобы перейти куда-то или по причине "я тащусь от этого зрелища", то он может быть готов к тому, что:
а. Ему будет показываться в каком месте он находится
б. Не факт, что сами данные будут при этом показываться (а они и не нужны).

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

Вообще, всё это делается. Просто руки не дошли у них. У людей, пишущих сетевые игры с огромными виртуальными пространствами дошли.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Роман Кошелев
Одни ищут способы "как сделать", другие -- оправдание "почему не делать"

Спасибо, Роман. Вас послушать, так я прямо к числу разработчиков Axapta отношусь. Надо у Navision узнать, какая у меня зарплата.

Цитата:

Изначально опубликовано Роман Кошелев
Есть масса подходов удовлетворить и пользователей и канал. Как пример (!) такая концепция

А почему Вы упорно не хотите рассматривать как концепцию реализацию Damgaard? Почему Вы не хотите считать это решением проблемы и называете это недоработкой? Ведь, если честно, как решение Damgaard, так и Ваше решение обладают как достоинствами, так и недостатками (извините, но назвать Ваш пример идеальным решением рука не поднимется; причины изложены выше).

Цитата:

Изначально опубликовано Роман Кошелев
Если пользователь тащит бегунок, чтобы наблюдать ползущие данные, то он будет готов к тому, чтобы:
а. Эти данные будут поставляться ему медленно

Вот я поэтому и говорю, подумайте, готовы ли Вы заплатить за эту мелочь замедлением работы.

Цитата:

Изначально опубликовано Роман Кошелев
Пропущенные данные можно отображать так: Извините | эта строка не успела | загрузиться

Давайте лучше так: Извините | Ваш канал связи | Ваш компьютер | или Вы сами | не позволяют загрузиться | данной строке

Цитата:

Изначально опубликовано Роман Кошелев
2. Если пользователь тащит бегунок, чтобы перейти куда-то или по причине "я тащусь от этого зрелища", то он может быть готов к тому, что:
...
б. Не факт, что сами данные будут при этом показываться (а они и не нужны).

А Вы пользователя спросить не забыли, нужны ли ему эти данные? Может быть, он на длину строчки проверяет. А это можно визуально сделать ой как быстро.

Цитата:

Изначально опубликовано Роман Кошелев
Алгоритмы подстройки подобных вещей просты и расчитываются из тех соображений, что человек не в состоянии читать более 20 строк в сек, например.

Пусть у нас во все записи входит поле, которое представляет собой строку, и она может быть пустой или нет. Теперь я хочу найти в таблице запись с пустым значением этого поля. Поверьте, я могу сказать гораздо быстрее, чем за 20 сек, является ли строчное поле в текущей записи пустым или нет. (NB Я не сверхчеловек, чего и Вам желаю )

Цитата:

Изначально опубликовано Роман Кошелев
Вообще, всё это делается. Просто руки не дошли у них. У людей, пишущих сетевые игры с огромными виртуальными пространствами дошли.

На самом деле считаю дискуссию достаточно бессмысленной. В сетевых играх Вы попробовали свой пример, и Вам понравилось. Но Axapta (к сожалению или нет, не знаю) не сетевая игра. Очень может быть, что такая концепция окажется здесь неприменимой. Сказать это наверняка невозможно, так как все что мы можем - это представлять, как же будет круто, если мы сделаем так-то и так-то. А вдруг, если мы это сделаем, круто не будет?

Да, кстати, не надо недооценивать программистов Navision (вообще, позиция "я умнее всех", по моему мнению, не самая лучшая). Очень может быть, что они пробовали сделать так, как Вы говорите (ну, не дословно, конечно, но что-то похожее может быть), и это их не удовлетворило.

Мое мнение, ищите хорошее в том, что уже есть, не нужно выдумывать свое решение и говорить всем, как же было бы хорошо, если бы сделали так, как я говорю.

[Роман Кошелев]

Действительно, развивать тему "как ползти бегунку/как бежать ползунку" не имеет смысла, тем более так подробно разбирать мой пример. (Как пример (!))

В конце только замечу, что критерии "кто умнее" тут не уместны, скорее уместны "кому это надо". А надо это пользователям. Таким Как Сергей (Buh). Ибо им с этим работать. И они ожидают адекватного поведения системы.

Всё.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Роман Кошелев
В конце только замечу, что критерии "кто умнее" тут не уместны, скорее уместны "кому это надо". А надо это пользователям. Таким Как Сергей (Buh). Ибо им с этим работать. И они ожидают адекватного поведения системы.

Что точно нужно пользователям, так это понять смысл того, что сделано. Поведение, которое реализовано в Axapta, называть неадектватным я бы не стал. Следует научиться извлекать пользу из этого поведения, а не пытаться засунуть Axapta в рамки, для нее не предназначенные.

[mazzy]

Я согласен с Max'ом.
Конечно и стремиться к лучшему надо.
Но прежде стоит понять почему сделано именно так.

Надо помнить, что
Идеальное решение требует бесконечных ресурсов

Еще один пример компромисса:
В заказах и закупках итоги не показываются сразу.
Для того, чтобы получить итоги пользователь должен нажать Запросы \ Итоги.
Меня, например, часто спрашивают почему сделано так?
Почему итоги по заказу/закупке не вынесены прямо на форму?

Приходится начинать с того, что:
если бы итоги были непосредственно на форме, то программа должна была бы обновлять итоги при каждом изменении в любой строке заказа/закупки. Т.е. изменили количество - пересчитай итоги, изменили скидку - пересчтиай итоги, изменили цену/сумма - тут уж сам бог велел - пересчитай итоги. А теперь представьте, что работает 10-20-30 менеджеров. И каждый вбивает строки.
Что будет с сервером?



Конечно и Роман прав: нужно работать в сторону улучшения. Обязательно.
Но перед тем как пожелать что-то переделать, стоит подумать - сколько я готов заплатить за это улучшуние? (Деньгами, временем, увеличиенными требваниями к железу и т.п.)

[Lazy_Tiger]

2mazzy: в данном конкретном примере, сервер не причем, ибо это на раз-два считается на стороне клиента, без дергания сервера. А даже если и на сервере, то извините конечно, но я не видел еще закупок/заказов с количеством строк более 200-300, а посчитать сумму по столбцу из в среднем 100 строк, даже если это будет делать 1000 клиентов одновременно, во что я не верю, это ерунда. Но еще раз подчеркну, до тех пор пока не сказали сохранить заказ, его вообще на сервер ложить как то странно.

Мы то ж программисты, давайте хоть другу другу лапшу не вешать на уши... Ладно б менеджер-менеджеру расказывал, некрасиво.

2max: Оставим в покое "бегунок", его поведение как раз не вызывает сколько-нибудь серьезных замечаний, кроме "непривычно". Раскажите же нам, чем кроме элементарных ошибок в коде, можно объяснить столь ммм... _НЕСТАНДАРТНОЕ_ и _НЕПРИЕМЛЕМОЕ_ поведение окон о котором я писал в самом начале? Более того, это _частично_ поправлено в 2.5 SP3 (т.е. спустя 5 релизов после того, как лично я впервые написал об этом в Навижн).

Где гарантия, что найдя ошибку в функционале, я получу ее исправление в сколько нибудь-разумные сроки? Лично я, за такие деньги считаю разумным срок в неделю МАКСИМУМ. Кто нибудь имел уже опыт таких обращений?

[Pavel]

Negative
Опыт обращений и сроки реакции на них не вызывают таких ярких и светлых воспоминаний, как презентация менеджера отдела продаж.

Creative
Иногда положительно срабатывает доведение данной информации до руководителей (президента или коммерческого директора) компании поставщика. Поддержка начинает реагировать более оперативно и со слезами на глазах радуются каждому твоему вопросу.

С уважением.