Galkov, да вроде на топике MT_String обсуждают. Ты же пишешь, что он не функционален, не означает ли это отход от него вообще, или изменение его алгоритма работы так, что он будет совсем не совместим с нынешним? Я просто спрашиваю, и ничего более.

Означает изменение формата Строки, и все что из этого (и только из этого) следует.
Что именно формат Строки является источником проблем - написал уже не один раз.
Будет не совместим.

Лучше бы - более. Настолько, чтобы переспрашивать не приходилось.
Кстати, связи с предыдущим вопросом - так и не уловил.

Кстати о птичках.. Сравниваю строки


[size=-2]------ Добавлено в 16:23
не то прицепил. Найду- выложу

Не надо выкладывать - смотреть небуду.
Мне достаточно основополагаещего: гарантий того, что ВСЕМ элементам будет по барабану - НЕТ.

[size=-2]------ Добавлено в 16:35
И, тоже кстати, если цель есть - "прокукарекать", то мне это тем более неинтересно.

Ага, со стороны integer - верно
А со стороны string - нет.

Я спрашивал к чему, а к тому, что MT_String широко используется для преобразования потока на выходе компонента SQLite_Query в разделенную строку для ввода в таблицу. Я и спрашивал -- останется ли эта совместимость?

Правильно ли я понял: постановка задачи для MT_String должна исходить из прямой совместимости с StringTable.doAdd, а взаимообратимость СВОИХ же методов - пофиг

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

А что, FormatStr с этим не справится
Да и вообще, это личное дело StringTable - метод приема для MT не противопоказан.


Да без проблем.
Если думать ДО того как делаешь, а не ПОСЛЕ.
Скажем у меня формат такой:
<StrLen1,Type1>String1<StrLen2,Type2>String2....

Вариантов для такой ерунды - сколько хочешь. Где тут проблемы

добавлен doMTString


заметка: формат с одним разделителем удобен во многих случаях, где строки в том или ином виде могут быть просмотрены или отредактированны пользователем. Выдача и парсинг результата в таком формате очевидно обратим на 100%, но пригодит исключительно для использования внутри схемы. Вероятно даже стоит делать отдельный элемент для сохранения МТ в данном формате как в строках, так и в Stream

Здравствуйте. Был в отпуске и пропустил маленько. Пока doMTString еще не устоялся, я бы проедложил добавить в MT_String
[Property]
toType=Приведение выходных даных к определенному типу|4|0|Auto,String,Integer,Real

И это не имеет никакого отношения к элементам из вкладки MT
Есть строковая задача - делайте элемент на вкладку <Строки>, есть другая - делайте другой элемент. Есть третья - метод doAddMT.

Такие топики будут появляться.
Куда это интересно делось понимание: "Пользователь имеет право ничего на знать"
Вот обратимость и нужна, чтобы не копаться в кишках.
И именно поэтому БУДУТ появляться такие топики.
Сделано фуфло, говоря языком нашего коллеги. И взрослыми мы становимся когда перестаем бояться этого признавать.
Да, и у меня порой фуфло получается. Вот только я не держусь за него, а пытаюсь понять, что следует изменить в своих базовых понятиях (привычках) чтобы потом это не получалось.

А впрочем все - про MT_String делайте что хотите.
От меня больше слова не дождетесь - сами расказывайте новичкам, что конверторы после обратного преобразования НЕОБХОДИМО ставить по причине:

поправка: их необходимо ставить только при использование предложенного метода. Старый способ - никто не отменял. Добавить еще один - никто не запрещает.

Редактировалось 5 раз(а), последний 2021-05-21 09:56:53

когда делался StringTable потоков типа МТ даже в проекте не было.