TsYekaterinaШтифт 2х14
Штифт 2х16
Штифт 2х4
Штифт 2х5

Хмммм....

Это всё-таки правильный конечный результат или нет?????


В ровно таком виде вам даже писать ничего не надо, только попросить дерево отсортироваться - и оно само отсортируется построчно.

Потому что текст "16" меньше, чем текст "2" - первая буквоцифра меньше, остальное не волнует
А вот число 16 больше, чем число 2, если его выделить из текста

и какая вам сортировка на самом деле нужна я уже не понимаю

TsYekaterina,

тогда прямая вам дорого в Гугл

https://www.google.ru/search?q=delphi alphanumeric comparison

например первые два результата

https://www.experts-exchange.com/questions/23086281/Natural-Order-String-Sort-Compare-in-Delphi.html
http://forum.lazarus.freepascal.org/index.php?topic=24450.0

только имейте в виду, что это просто обсуждения вопроса между делом, и насколько тамошними заримсовками можно пользоваться - они для этого в общем случае и не предназначены: http://www.gunsmoker.ru/2010/05/90.html

чччДОчень простой алгоритм: загрузи текст в TStringList

Это медленно, TList<string> лучше

Но.... это в предположении что у нее есть строки и только строки, нет никаких реальных данных за этими строками (объекта, записи, артикула на складе или в ценнике - ничего нет, только строки)

А оно должно быть

и сортировтаь надо будет реальные объекты, а не только строки из объектов выдранные

чччД,

я именно поэтому избегал называть конкретные классы, а когда называл - называл сразу несколько кандидатов

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

В принципе, там вполне может быть TStringList - для того, чтобы в .Objects[i] хранить скастованный указатель на record с реальными данными, например. В 1990-х это была стандартная практика.

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

тем более тьфу-тьфу кажется человек готов учиться сам, а не требовать готового кода

чччДразбор исходных строк. Не будем мудрить:

кстати, хороший пример для филиппики Раймонда Чена про программы с форумов

потому что твой парсер при случае "123.24.543" назовёт одним числом. И "212-85-06" тоже за число посчитает. И ".0123" тоже, хотя это уже серая зона.
Такие дела....

чччД,

"говнокода" (с) на форумах и так полно, зачем его количество увеличивать?

я даже в функцию с E-E не вчитывался внимательно, хотя она как минимум про ситуацию "две точки" в курсе

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

я человеку объяснял где искать удочки
ты вместо удочек дал ему рыбу
второй свежести, как внезапно (с) оказалось
но виноват оказываюсь я

пичалька

TsYekaterinaкак-то можно отсортировать данные в каждом узле отдельно?

Ещё раз прочитай 21176860 и покажи как ты это пыталась реализовать и что получиось.

white_niggerНадо, используя мозг, придумать алгоритм удовлетворяющий вашим критериям

А именно:
Как рубить названия на отдельные части?
Какие типы частей могут быть и как это определять?
Как сравнивать части того или иного типа.

А самое правильное (если возможно) было бы не строками заниматься, а тащить через программу "паспорт изделия" - типа record или class, в котором все параметры будут отдельно и явно прописаны как разные переменные.

У тебя сейчас где-то есть нормальное представление о предметах.
Скажем, винт характеризуется
0) тем, что он винт, а не болт
1) длиной
2) диаметром (строго говоря, двумя диаметрами)
3) типом головки (потайная, полукруглая, ...)
4) типом отвертки (плоский шлиц, крест, 6-гранник, ....)
5) диаметром головки
6) возможно, высотой(длиной) головки
7) направлением резьбы
8) шагом резьбы ( или наклоном )
9) саморез или нужно предварительно сверлить
10) для какого материала - в дерево вкручиивать, в пластик, в металл....
....и вероятно есть ещё разные признаки.

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

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

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

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

У тебя же получилось, что некоторая информация из паспортов была отброшена, некоторая же была свалена в одну строку, полу-формализованную, полу-стандартную.
И тебе сейчас нужно рзобрать (parse) строку и попытаться из неё извлечь это информацию обратно.
Задача нечёткая и неприятная.

Да, если тебе нужна только сортировка (а не нужен поиск/фильтр, нет (и никогда не будет) задачи покупателю/продавцу "показать винты и болты длиной от 3 до 5 см") то полный парсинг не нужен, достаточно упрощённого. Но во-первых и это медленнее, чем прямое сравнения регулярных паспортов.

A во-вторых "задача нечёткая": вот у тебя винт в середине "....gx6.ВТ1-0...." а над ним и под ним "....gx6.36.01...."
Вот приедут эти строки в твой компаратор.
Поползёт он по ним.
".....gx", а дальше цифра - это кусок-строка, сравниваем через AnsiTextCompare, получаем 0, надо сравнивтаь дальше

Ползёт дальше "....6." - это число шесть и... точка это уже новая строка или всё ещё число?
Ну ладно, допустим (оооочень плохое слово), что точка - всегда разделят блоки, а дробная часть всегда отбивается запятыми и никогда точками (а если мы не угадали, что тогда?), но пока - д-о-п-у-с-т-и-м.

...."6" в обеих строках. Кусок-число. Превращаем его из строки в число (операция сама по себе долгая и чреватая ошибками) и сравниваем две переменных integer или single. Sign( int1-int2 ) = 0, опять равенство, опять надо дальше сравнивать.

Ползём по двум строка синхронно дальше.

строка 2: "." и за ним цифра 3. Значит кусок-строка была один символ "." , а дальше будет кусок-число
строка 1: ".ВТ" и за ним цифра 1. Значит кусок строка будет ".ВТ" и эти два куска сравниваем в AnsiTextCompare - тут строки разные, результат будет не ноль, и сравнение заканчиваем.

А вот ЕСЛИ БЫ сравнение не закончилось, то дальше бы сравнивали числа "36" (ил "36.016") и "1" (из "1-0").
Т.е. вероятно (слово настолько же отвратительное, как "допустим") пошла рассинхронизация, начали вероятно сравнивать разные по смыслу блоки.

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

1) добиться, чтобы до самого списка доходили не просто полу-бессистемные строки, а полноценные РЕГУЛЯРНЫЕ паспорта изделий. Сортировку/поиск/фильтрацию делать по ним. Это наиболее "правильный" и быстрый способ, но не всегда возможный.
2) сделать полноценный парсинг строк, восстановление типа паспорт и заполнение всех полей, которые удастся заполнить (и отметку какие поля заполнены, какие нет), потом сортировку по временному паспорту. Это наиболее медленный способ. Но ты хотя бы сама будешь понимать что и с чем ты сравниваешь.
3) сделать халявный полу-парсинг, понадеявшись что большая часть строк заполнена более-менее стандартно, а на редкие исключения наплевать, виноват кто-то другой будет. Это то, о чём тебе с самого начала говорили.

TsYekaterinaШтифт 2.2х16.Хим.Окс.прм
Штифт 2.2х20
Штифт 2.3х16.019

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

А на картинке твоей - "Винт В.М2,5-gx6....." - тут дробная часть отбивается запятыми. А точки отбивают только смысловые блоки.

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

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

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

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

Ведь не даром во всех магазинах/складах есть артикул (он же SKU - Storage Kept Unit number), уникальный идентификатор, по которому можно выдернуть "карточку товара", где в явном и раздельном виде будут (должны быть) описаны его свойства.

чччД,

человек НЕ программист, не математик.

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

"ты похожа на программиста - иди затыкай дырку"