Вопрос по сортировке очереди.
Можно ли сделать по необходимости сортировку по такому-то полю (стринговому) с учетом, либо без учета регистра?
Игорь Смирнов
Написал: ClaList(2)
Сортировка QUEUE
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
-
Гость
Здравствуйте
Хм, сам не пробовал, но есть мысль обратится за помощью к LOCALE параметр CLACOLSEQ
Что-то вроде:
LOCALE('CLACOLSEQ', нужная_последовательность_сортировки) ! назначаем
sort(queue, нужное_поле) ! упорядочиваем
locale(файл_по_умолчанию.env) ! восстанавливаем
Сергей - chusha@mail333.com ; chusha@hotbox.ru
А еще советую почитать доку в C61. Для сортировки и поиска можно задавать СВОИ функции, которые и будут выполнять эти задачи. Так что - "наворотить" там можно столько всего!
=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Да, наверное придется через LOCALE действовать - других путей я не нашел.
Ну, разве что специально создавать файл, который набивать из этой очереди, задать ему регистрочувствительный ключ, а потом делать стандартную процедуру Browse...
Но это уже полный абсурд.
В-общем, попробую с ЛОКАЛЕ.
Igor Smirnov
Файл это точно абсурд. В общем случае можно завести в очереди дополнительное поле, куда записывать сортирующее выражение - в данном случае - просто UPPER().
WBR, Nick Tsigouro
Ну зачем так сразу? В 6.0 есть процедура сортировки очереди с пользовательской командой сравнения. И в 5.5 кажись работает, Олег Руденко писал. На крайняк сделать в Sort два текстовых поля - простое и в Uppercase и сортировать по одному из них...
---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439
А что это пользовательская команда сравнения?
С уважением,
Леонид Мартюшев leonid@opfr.komi.com
Не команда, функция. Что-то у меня думается одно, а пишется другое, вместо Queue написал Sort. И ведь не пил...
Посмотри Sort(Queue) в Help на 6.0
---------------------------------------
C уважением,
Юрий Философов
Что-то мне подсказывает, что LOCALE здесь никаким образом роли не играет. Ибо изначально сортировка очереди регистрочувствительная.
А локаль используется при регистронечувствительной сортировке. Следовательно...
Следовательно, добавляем в очередь поле SORT_Q STRING(20)
И делаем сортировку уже по этому полю.
А заполняем его в соответствии с требуемым типом сортировки.
Можно это делать на этапе добавления записей, можно (если очередь небольшая) написать функцию сортировки.
С уважением,
В.Смелик.
LOCALE нормально работает - все ОК
Igor Smirnov
Написал: ClaList(2)
Хм, сам не пробовал, но есть мысль обратится за помощью к LOCALE параметр CLACOLSEQ
Что-то вроде:
LOCALE('CLACOLSEQ', нужная_последовательность_сортировки) ! назначаем
sort(queue, нужное_поле) ! упорядочиваем
locale(файл_по_умолчанию.env) ! восстанавливаем
Сергей - chusha@mail333.com ; chusha@hotbox.ru
А еще советую почитать доку в C61. Для сортировки и поиска можно задавать СВОИ функции, которые и будут выполнять эти задачи. Так что - "наворотить" там можно столько всего!
=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Да, наверное придется через LOCALE действовать - других путей я не нашел.
Ну, разве что специально создавать файл, который набивать из этой очереди, задать ему регистрочувствительный ключ, а потом делать стандартную процедуру Browse...
Но это уже полный абсурд.
В-общем, попробую с ЛОКАЛЕ.
Igor Smirnov
Файл это точно абсурд. В общем случае можно завести в очереди дополнительное поле, куда записывать сортирующее выражение - в данном случае - просто UPPER().
WBR, Nick Tsigouro
Ну зачем так сразу? В 6.0 есть процедура сортировки очереди с пользовательской командой сравнения. И в 5.5 кажись работает, Олег Руденко писал. На крайняк сделать в Sort два текстовых поля - простое и в Uppercase и сортировать по одному из них...
---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439
А что это пользовательская команда сравнения?
С уважением,
Леонид Мартюшев leonid@opfr.komi.com
Не команда, функция. Что-то у меня думается одно, а пишется другое, вместо Queue написал Sort. И ведь не пил...
Посмотри Sort(Queue) в Help на 6.0
---------------------------------------
C уважением,
Юрий Философов
Что-то мне подсказывает, что LOCALE здесь никаким образом роли не играет. Ибо изначально сортировка очереди регистрочувствительная.
А локаль используется при регистронечувствительной сортировке. Следовательно...
Следовательно, добавляем в очередь поле SORT_Q STRING(20)
И делаем сортировку уже по этому полю.
А заполняем его в соответствии с требуемым типом сортировки.
Можно это делать на этапе добавления записей, можно (если очередь небольшая) написать функцию сортировки.
С уважением,
В.Смелик.
LOCALE нормально работает - все ОК
Igor Smirnov
Написал: ClaList(2)
-
Гость
На самом деле задача стоит - делать именно ЧУВСТВИТЕЛЬНУЮ к регистру сортировку.
А функция SORT делает это "НЕЧУВСТВИТЕЛЬНО" - проверено на практике.
Причем проверялось все на чисто латинских словах - русских букв там и рядом не стояло.
Изначально было так (к примеру):
bus
Dialogue
wild
WWW
После того, как перед SORT я добавил команду
LOCALE('CLACOLSEQ','ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz')
стало сортироваться так:
Dialogue
WWW
bus
wild
То есть, в частном случае задача была решена.
Но на самом деле нужно общее решение - ибо могут в конце концов "попасться" не только латинские буквы, но и русские, а также всякие другие символы.
Получается, что по идее в LOCALE('CLACOLSEQ",....) нужно будет прописать практически всю таблицу ASCII - от 32-го символа до 255-го (первые 31 считаются "непечатными").
Ситуация какая-то непонятная. Неужели разработчики Клариона не сталкивались с тем, что возникает необходимость сортировки очередей по разным алгоритмам - причем, по известным алгоритмам. Они же предусмотрели возможность ключей физической таблицы с вариантами чувствительностиили нечувствительности к регистру.
И самое забавное, что в хелпе о регистрочувствительной сортировке очереди - ни слова.
Игорь Смирнов
Общее решение состоит в том, что CLACOLSEQ не зашивается в программу а хранится во внешнем файле - ini или если их надо много и разных - в таблице БД.
WBR, Nick Tsigouro
А ее система и так дает - зачем же масло масляное делать?
Нужна на самом деле именно ЧУВСТВИТЕЛЬНОСТЬ.
Игорь Смирнов
Система сама ничего не дает. Значит такой CLACOLSEQ.
Точнее FORMAT(VAL(Str[1]),@n03) & Str
WBR, Nick Tsigouro
Не юзабельно. Т.к. пригодно только для случая, когда не требуется сортировка по соседним символам.
По ходу диалога я вник в проблему
Просто я привык к тому, что первое действие в новой APP - выставить правильную локаль. Соответственно, и все сортировки у меня были регистрочувствительные.
Да и поведение приложения без явно указанной локали мне всегда казалось весьма странным. Особенно в русских буквах.
С уважением,
Владимир Смелик
Ну да, для регистрочуствительных кодов (паролей - "аБв" vs. "абВ") маловато будет. А для имен собственных - вполне.
WBR, Nick Tsigouro
Просто Кларион жестко знает про соответствие заглавных и строчных букв для латинского (читай - английского) алфавита. А больше на эту тему не знает ничего:):)
И сортирует такие значения регистронечувствительно - типа, вот я какой умный.
А если попадаются, скажем, русские значения, то ситуация меняется. Так как Кларион ничего не значет про алфавит русского языка (мы же нигде ему CLACOLSEQ не подсовываем), то он начинает сортировать эти буквы в так называемом бинарном порядке - то есть, просто по возрастанию ASCII-кодов.
С другой стороны, в кодовой таблице русские буквы расположены почти на 100% так, что алфаитный порядок совпадает с бинарным (исключения - русская буква Ё, а также специфические буквы украинского, белорусского и южнославянских языков, которые находятся до основного кириллического алфавита).
Поэтому при использовании букв только базовой кириллицы создается визуальное впечатление регистрочувствительной сортировки. Но это - только лишь "кажимая видимость".
Потому что стоит только добавить в сортируемый список значение на ту же пресловутую букву "Ё", как сразу все и вскроется - эта самая "Ё" будет при сортировке помещена перед "А" - просто потому, что ее ASCII-код меньше.
Вот, собственно, и вся тайна.
Igor Smirnov
:):) Читаем хелп:
CLACOLSEQ=WINDOWS
CLACOLSEQ="string"
[...]
If this entry is omitted from the environment file, then the default ANSI ordering is used, not the windows default.
Сие означает, что если ничего нигде не задано, то сортировка будет регистрочуствительная, как для латиницы, так и для кириллицы.
TIP. В среде есть поиск файлов. Иногда поиск с использованием red файла много неожиданного открывает.
WBR, Nick Tsigouro
Написал: ClaList(2)
А функция SORT делает это "НЕЧУВСТВИТЕЛЬНО" - проверено на практике.
Причем проверялось все на чисто латинских словах - русских букв там и рядом не стояло.
Изначально было так (к примеру):
bus
Dialogue
wild
WWW
После того, как перед SORT я добавил команду
LOCALE('CLACOLSEQ','ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz')
стало сортироваться так:
Dialogue
WWW
bus
wild
То есть, в частном случае задача была решена.
Но на самом деле нужно общее решение - ибо могут в конце концов "попасться" не только латинские буквы, но и русские, а также всякие другие символы.
Получается, что по идее в LOCALE('CLACOLSEQ",....) нужно будет прописать практически всю таблицу ASCII - от 32-го символа до 255-го (первые 31 считаются "непечатными").
Ситуация какая-то непонятная. Неужели разработчики Клариона не сталкивались с тем, что возникает необходимость сортировки очередей по разным алгоритмам - причем, по известным алгоритмам. Они же предусмотрели возможность ключей физической таблицы с вариантами чувствительностиили нечувствительности к регистру.
И самое забавное, что в хелпе о регистрочувствительной сортировке очереди - ни слова.
Игорь Смирнов
Общее решение состоит в том, что CLACOLSEQ не зашивается в программу а хранится во внешнем файле - ini или если их надо много и разных - в таблице БД.
Так как бы само понятно - сортируется по правилам сравнения строк.И самое забавное, что в хелпе о регистрочувствительной сортировке очереди - ни слова.
WBR, Nick Tsigouro
С таким дополнительным полем как раз и будет реализована НЕЧУВСТВИТЕЛЬНОСТЬ к регистру.В общем случае можно завести в очереди дополнительное поле, куда записывать сортирующее выражение - в данном случае - просто UPPER().
А ее система и так дает - зачем же масло масляное делать?
Нужна на самом деле именно ЧУВСТВИТЕЛЬНОСТЬ.
Игорь Смирнов
Система сама ничего не дает. Значит такой CLACOLSEQ.
Пардон. Я понял наоборот. Тогда VAL(Str[1]) & StrНужна на самом деле именно ЧУВСТВИТЕЛЬНОСТЬ.
Точнее FORMAT(VAL(Str[1]),@n03) & Str
WBR, Nick Tsigouro
Не юзабельно. Т.к. пригодно только для случая, когда не требуется сортировка по соседним символам.
По ходу диалога я вник в проблему
Просто я привык к тому, что первое действие в новой APP - выставить правильную локаль. Соответственно, и все сортировки у меня были регистрочувствительные.Да и поведение приложения без явно указанной локали мне всегда казалось весьма странным. Особенно в русских буквах.
С уважением,
Владимир Смелик
Ну да, для регистрочуствительных кодов (паролей - "аБв" vs. "абВ") маловато будет. А для имен собственных - вполне.
WBR, Nick Tsigouro
Никакого CLACOLSEQ'а нигде в программе не прописано.Система сама ничего не дает. Значит такой CLACOLSEQ.
Просто Кларион жестко знает про соответствие заглавных и строчных букв для латинского (читай - английского) алфавита. А больше на эту тему не знает ничего
:):)И сортирует такие значения регистронечувствительно - типа, вот я какой умный.
А если попадаются, скажем, русские значения, то ситуация меняется. Так как Кларион ничего не значет про алфавит русского языка (мы же нигде ему CLACOLSEQ не подсовываем), то он начинает сортировать эти буквы в так называемом бинарном порядке - то есть, просто по возрастанию ASCII-кодов.
С другой стороны, в кодовой таблице русские буквы расположены почти на 100% так, что алфаитный порядок совпадает с бинарным (исключения - русская буква Ё, а также специфические буквы украинского, белорусского и южнославянских языков, которые находятся до основного кириллического алфавита).
Поэтому при использовании букв только базовой кириллицы создается визуальное впечатление регистрочувствительной сортировки. Но это - только лишь "кажимая видимость".
Потому что стоит только добавить в сортируемый список значение на ту же пресловутую букву "Ё", как сразу все и вскроется - эта самая "Ё" будет при сортировке помещена перед "А" - просто потому, что ее ASCII-код меньше.
Вот, собственно, и вся тайна.
Igor Smirnov
:):) Читаем хелп:CLACOLSEQ=WINDOWS
CLACOLSEQ="string"
[...]
If this entry is omitted from the environment file, then the default ANSI ordering is used, not the windows default.
Сие означает, что если ничего нигде не задано, то сортировка будет регистрочуствительная, как для латиницы, так и для кириллицы.
Чудес в программировании не бывает. "Ищите и обрящете."И сортирует такие значения регистронечувствительно - типа, вот я какой умный.
TIP. В среде есть поиск файлов. Иногда поиск с использованием red файла много неожиданного открывает.
WBR, Nick Tsigouro
Написал: ClaList(2)
