Форум » GUI » MiniGUI-Browse- поиск по букве » Ответить

MiniGUI-Browse- поиск по букве

valery2: Извините меня, но очень нужна помощь. С Clipperr-ом работаю давно, в Mini - нет и года. Начальству ну очень нужно поиск в прайс-листе по протому нажатию любой русской буквы. Не долго мудрствуя, определил все клавиши и, в частности русские _DefineHotKey ( , 0 , 192 , {|| poisk(chr(192))} ) // буква "А" и т.д. В Browse все цифры и латинские буквы проходят, а русские - никакой реакции. А начальству вынь да полож.

Ответов - 43, стр: 1 2 3 All

gfilatov: valery2 пишет: определил все клавиши Решение простое, но неэффективное Посмотрите, как это сделать грамотнее в примере из папки samples\Basic\DualBrowse (функция IncrementalSearch()).

valery2: Большое спасибо, попробую.

valery2: Посмотрел, попробовал - ну и наворочено. А мне-то всего и надо - в Browse по нажатию любой клавиши ( особенно русские буквы) не просто стать на запись, где есть эта буква, а вызвать мою функцию Poisk(rr), загнав туда, через параметр, эту самую букву, адальше эта самая функция сама уже будет формировать слова, фразы и осуществлять поиск.


Петр: valery2 пишет: Посмотрел, попробовал - ну и наворочено. Joe написал как смог Найдете более простое и эффективное решение - напишите Григорию, он с удовольствием опубликует.

valery2: Неужели ни у кого не вставала подобная проблема? В Clippere в Dbedit все это элементарно, в одну строчку. А сдесь ... Еслиб было время, да побольше опыта. Потому и прошу помощи.

MMK: valery2 пишет: Еслиб было время В GUI вроде есть TsBrows ,так там по одной букве поиск встроенный должен быть. Ну , а если сам ( в нем же ) то так: obi:bKeyChar={ |nKey| Poisk(nKey,oBi,oWn,oFld ) }

valery2: Спасибо за подсказку! Надо обжевать.

valery2: Еще раз спасибо, но всеэто не то. TsBrowse тянет за собой кучу переделок в уже существующей проге. А у меня в окне еще 2 Browse и им абсолютно не нужны эти навороты. В результате начинаю путаться с управлением и т.д. Не уверен, что переход полностью на TsBrowse по времени переделки программы целесообразней какого-нибудь собственного "изобретения".

КСС: Сейчас не могу предложить ничего конкретного, но несколько лет назад, когда ещё был только MiniGUI, я его тестил и озадачился тем же. И тогда я пошел по пути DBEDIT - нашел в исходнике с определением окон участок кода перехватывающий клавиши в BROWSE и просто добавил в конец (там кажется DO CASE) вызов своей функции. Это был просто эксперимент, но всё получилось. Как это лучше оформить для использования пока не знаю, но планирую вернуться к этому в ближайшие две недели.

valery2: КСС пишет:я пошел по пути DBEDIT - нашел в исходнике с определением окон участок кода перехватывающий клавиши в BROWSE и просто добавил в конец (там кажется DO CASE) вызов своей функции. Это чень интересно. Нельзя-ли ссылочку на исходник DBEDIT, или сам текст исходника на moongo@mail.ru ?!! Весьма презнателен заранее !

valery2: КСС Прошу прощения - Весьма прИзнателен .

Петр: valery2, КСС в принципе предложил тот же путь решения (в общем правильный), что и Joe, только в худшем исполнении. В лучшем случае вы можете получить клон MiniGUI, который не сможете поддерживать. Ну, а в в худшем.. Григорий - пример Joe нужно убирать, пусть пользователи учатся использовать SET EVENTS FUNCTION TO MYEVENTS И пожалуйста исправьте этот фрагмент: Case GetGridvKey(lParam) == 46 // DEL If _HMG_aControlPicture == .t.

КСС: Эта обработка кнопок описана, кажется, в файле исходников h_windows.prg. Как я уже писал, дело было давно и это был эксперимент. Написал это здесь в качестве зацепки для других программистов. Планирую в ближайшее время повторить изыскания, потому что пишу программу на MiniGUI-Ext. Если что-то вразумительное получится - выложу.

valery2: Петр пишет: КСС в принципе предложил тот же путь решения (в общем правильный), что и Joe, только в худшем исполнении. Ваши намерения понятны, но : 1. Используя пример JOE , сразу исчезает MENU в ext форме 2. В h_windows.prg огромное количество переопределенных функций и переменных, существующих в библиотеках, а расследование, что - не нужно и что за собой тянет их удаление занимает много времени. 3. Вы пишите:пусть пользователи учатся использовать SET EVENTS FUNCTION TO MYEVENTS Но по EVENTS практически ничего нет в документации, а примеров - кот наплакал. Теперь Вы вообще хотите убрать пример JOE. А на чем учиться?

gfilatov: Петр пишет: исправьте этот фрагмент: Case GetGridvKey(lParam) == 46 // DEL If _HMG_aControlPicture == .t. Петр Спасибо! Я уже поправил этот свой ляп в новом релизе Может, есть еще какие-либо дополнения для нового релиза?

Петр: "В общем правильный" путь - это переопределение реакции окна BROWSE на событие LVN_KEYDOWN. MiniGUI позволяет делать это в два способа - или переопределять функцию Events или через SET EVENTS FUNCTION TO определить пользовательскую функцию, которая будет делать какие-то специфические для программы вещи и потом уже вызывать глобальную Events() В не зависимости то того, как вы будете переопределять Events(), вы можете столкнуться с проблемой клонов и дальшей несовместимости с сл.версиями MiniGUI (если такие будут) - это и в случае изменения исходников самой библиотеки и в варианте Joe (включении в исходники программы модифицированной Events). Вы это сами подтвердили, приведя пример с MENU ext. Раз так, то нечего пропагандировать плохой стиль программирования. Да - это допустимо, но вы должны делать это осознанно и только в случае если нет других возможностей или вы решили сделать свой клон библиотеки. Теперь о h_windows.prg - я предлагал Григорию вынести Events в отдельный файл, к сожалению это предложение было проигнорировано. Вопрос о документации всплывает не первый раз, и опять же к сожалению я должен констатировать, что у MiniGUI Ext нет сообщества. Желающих работать над совершенствованием библиотеки (исходники, документация) - фактически нет. И количеством примеров это компенсировать нельзя.

gfilatov: Петр пишет: Желающих работать над совершенствованием библиотеки (исходники, документация) - фактически нет. Подтверждением этого может служить обсуждение библиотеки на этом форуме (иногда создается впечатление, что я беседую сам с собой ) Петр пишет: количеством примеров это компенсировать нельзя. Снова согласен, особенно, если эти примеры обычно никто не изучает... Петр пишет: я предлагал Григорию вынести Events в отдельный файл Это не проблема! Если можно, повторите снова свою аргументацию по этому вопросу

valery2: Простите, Петр, но никто здесь не пытается "пропагандировать плохой стиль программирования". Происходит только взаимный обмен опытом и обучение, как на своих так и на чужых положительных и ошибочных примерах. Или это Вы решили нас отшлёпать по попке (настроение такое)? А если серьезно, Вы могли обратить внимание, что в MiniGUI я недавно, и многое для меня еще неясно. Поэтому приму ЛЮБУЮ, но достаточно внятную, помощь.

valery2: В догонку. Вставил следующее: Function MyEvents ( hWnd, nMsg, wParam, lParam ) *------------------------------------------------------------------------------* Local i, x if nMsg == WM_NOTIFY IF GetNotifyCode ( lParam ) == LVN_KEYDOWN ppp(lParam) endif else Events ( hWnd, nMsg, wParam, lParam ) endif Return (0) procedure ppp(lparam) if chr(GetGridvKey( lParam )) $ '1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNMйцукенгшщзхъфывапролджэячсмитьбюёЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЭЯЧСМИТЬБЮЁ' msginfo(chr(GetGridvKey( lParam ))) endif return Прекрасно реагирует, но только на цифры и латинские бувы (причем, почему-то shr() выдает на экран латинские буквы только в верхнем регистре, хотя жму и так и этак), на кирилицу-ноль внимания!

gfilatov: Петр пишет: Теперь о h_windows.prg - я предлагал Григорию вынести Events в отдельный файл, к сожалению это предложение было проигнорировано. Выделил функцию Events() вместе со связанными с ней функциями _OnGetMinMaxInfo(), _SetNextFocus(), _PushEventInfo() и _PopEventInfo() в отдельный h_events.prg



полная версия страницы