Синхронизация матриц

[Sova_imported]

День добрый всем!
Возникла идея поместить на одну форму две матрицы, причем обе имеют одну запись-источник: товар, но расчет в них ведется из разных таблиц, и соответственно, обе они должны одинаково двигаться вверх-вниз про перемещении по товару (первой матрице).
В принципе, физически так оно и происходит - при скроллинге, если на первой матрице кур-рекорд стоит на Товаре10, то и на второй матрице кур-рекорд стоит на Товаре10. Но вот загвоздка - сам курсор, визуальное отображение этого процесса - несинхронизирован. Первый курсор может стоять двадцатым сверху, а второй - первым сверху, или пятым, и т.п. Если перескочить на вторую матрицу, и ее листать, то так же картина наблюдается, но уже наоборот: товары помечены одинаковые, но визуально курсоры стоят в разных местах, и даже совместить в одну линию их невозможно ручной подгонкой, все равно хоть на одну строку, а сдвижка будет...

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

[zuzka]

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

Собственно это всего лишь идея, как она будет работать - неизвестно))

[romeo]

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

[Sova_imported]

Цитата:

Сообщение от zuzka

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

Собственно это всего лишь идея, как она будет работать - неизвестно))

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

[Sova_imported]

Цитата:

Сообщение от romeo

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

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

[zuzka]

Цитата:

Сообщение от Sova

Цитата:

Сообщение от zuzka

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

Собственно это всего лишь идея, как она будет работать - неизвестно))

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

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

Нав не умеет - его надо учить. Завтра посмотрю что можно сделать. Думаю никаких проблем не будет.

[Sova_imported]

Цитата:

Сообщение от zuzka

у вас в матриксе отображаются 11 строк - как пример -

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

[Sancho]

изврат, конечно, но встречал следующий вариант:
в каждой ячейке матраса 2 значения через '\'

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

[Yoil]

Толково, кстати

[Sova_imported]

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

[InTacto]

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

[Sova_imported]

Цитата:

Сообщение от InTacto

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

Хммм... а как это - матрицу разделить на две части. Вы пробовали? Матрица, как форма, всегда одна, привязанная к родительской таблице. Если надо вторую - приляпывается еще одна форма, которую невозможно синхронизировать с визуальным движением курсора по первой. Я как раз и вылезла с этой проблемой.
Нав у нас старый.

[InTacto]

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

[Sova_imported]

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