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

Ибо использование велосипеда эффективно когда один и тот же метод применяется к разным контролам - тогда, ДА.

Нужная вещь, Об этом разговор уже поднимался. Я вот думаю, а ComboBox'y нужны ли все эти навороты (особенно с доп данными)?

[size=-3](в сторону, задумчиво) Нет, это уже deja-vu какое-то...


Гнело меня то, что, как мне казалось, узнать CurIndex через нижнюю точку Index с выключенным _prop_SelectAdd нельзя. Оказалось, плохо матчасть (KOL) крутил...





Galkov, nesco, вопрос, кстати, концептуальный, и даже немного перекликается с "мультипроцессорностью".

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

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


Я, как "персона опытная", считаю, что на оба вопроса следует ответить положительно. Более того, я считаю, что и метод _Add (используемый для массива строк) тоже надо бы функцией сделать, а в ArrayRW добавить выдачу индекса после doAdd (e.g. через собвытие onAdd).

Что вы подразумеваете под частичным поиском

То, что сейчас и сделано

Я пожалуй парсинг на последний символ сделаю: если "*" - значит частичный...

Galkov, а может всё-таки через св-во, типа "SearchType:Exact/Soft"

Кстати, в частичном случае, и индекс начала поиска - не бессмысленен....

Посмотрите чего получилось: rev 332
Вроде по мелочам все: так лучше, это лучше перенести, и эдак тоже правильно - и вот результат
Поэтому просьба прогнать ВСЕ примерчики, что употреблялись до этого для тестинга

И тщательнЕе, пожалуйста, тщательнЕе...
большой объем изменений опять - вероятность баги возрастает

[size=-2]------ Добавлено в 09:36
nesco, в качестве "разборки полетов", коротко:

1) ф-ии ReadXXX были "обычными" до введения MT, после введения, адаптированись ИМЕННО они, а коды элементов не трогались. Всякий ReadXXX просто "снимает" экземпляр с головы MT для случая чтения из потока.

2) никогда не уничтожай данные, если не ты их делал. Не твое - не лапай

3) для создания MT-данных вовсе не обязательно выпрыгивать из трусов с динамическими конструкторами. Показывал же тебе, как это делается при "внешней сортировке".

а если они мне на входе или выходе не нужны? Все эти данные пытаются притулиться к моим.

Тому кто их сделал, совершенно по барабану твои проблемы. Сам их и решай.
А он решит свои - уничтожит то, что создал.

Galkov, да, уже понял и все почистил.

[size=-2]------ Добавлено в 12:28
iarspider, вот что я хочу сказать, насчет всего этого, особенно насчет использования хранения данных -- это совершенно неправильная концепция. Лист данных нужен для хранения индексов картинок, которые можно было сделать в этих контролах, но мы закрыли этот путь. Я предлагаю отказаться от этой концепции и пойти по пути прикрепления к контролам ImageList'a, и тогда, при помощи обработчика onDrawItem, можно будет выводить в поля контрола картинки перед текстом. ИМХО. Предлагаю обсудить эту концепцию.

nesco, вперёд и в путь. Но только как ListBoxEx (или как ImageListBox). Мультипроцессорность, однако.

Это здесь не уместно. А ты не задавался вопросом -- на кой ляд ListBox'y параллелное хранилище данных?. Это его нормальный ежим, когда рядом со строкой находится картинка (и для чего этим контролам onDrawItem?). Не знаю как для ListBox'a, а для ComboBox'a это точно исползуют (наша любимая черепаха имеет такой контрол). Ты говоришь использовать, а методы Galkov перекрыл в Win'e. Я предлагаю для улучшения функциональности, а не ради создания графического мультипроцессора. Один такой уже есть -- StringTable, ксати, единственный компонент, позволяющий сохранять ImageList'ы (такого метода даже в KOL'e нет).

В бух.системе, которую я для одной фирмы делаю на VC++, я записываю в это хранилище индекс записи в списке организаций, чтобы потом быстро получить путь к БД. Я не спорю, что можно и для хранения номера картинки использовать это хранилище.


Я ещё не купил новые очки (жду зарплату), поэтому ткни плиз носом, что перекрыто. Вроде доступ к ValArray у нас остался...

iarspider, Add перекрыт. Galkov переделал этом метод под мультипоточность. Хотя, в принципе, он мне и не мешает. Я поднял вопрос концепции, а не вопрос закрытости методов. Мне не проблема сделать такой компонент для себя, но я не хочу для себя, я хочу -- для всех, иначе, у меня просто пропадает интерес.