Форум » » Странное поведение BUFFER_INPUT при сравнении с строкой » Ответить
Странное поведение BUFFER_INPUT при сравнении с строкой
CEA: Здравствуйте! Потребовалось сделать ввод пароля. Контроллер второй серии. Цепочка такая: Text Entry -> Output Text Serial Join -> Buffer_Input в модуле SIMPL+. Предположим, вводим пароль "asd" , нажимаем кнопку, в PUSH кнопки сравнение содержимого Buffer Input с "asd" не истинно, почему то. В отладчике отлично видно, что в буфере только три байта, соответствующие символам. А вот Find("asd", <вход типа Buffer Input>) срабатывает. Т.е. как будто по факту в буфере более длинная строка. После замены Buffer_Input на String_Input все работает как ожидалось. Еще прикол - делаем размер буфера, скажем, 8 символов. Вводим в текстовое поле 1234. В отладчике уже ошибка: Error: Overflow on Buffer Input __PSW_STRING on Module: S-1.1.4.1. New = 10, Max = 8 Откуда переполнение?
Ответов - 5
Igor: CEA, буфер надо регулярно чистить. CLEARBUFFER.
Вячеслав: 1.Чистите буфер и Text Entry при переходе на страницу ввода пароля. В нём явно лишние непечатные символы, смотрите в представлении HEX ну и длину можно вывести для надежности в отладочный STRING_OUTPUT DEBUG$ Makestring(DEBUG$,"%s",Pass_buf); //эту лучше в hex представлении отобразить Makestring(DEBUG$,"length=%u",len(Pass_buf)); 2.Самое частое на моей практике в случае "вижу что совпадает, а find не срабатывает" это ошибка размерности переменной (не лезет просто) 3.Переполнение скорее всего от туда же, в буфере есть что то от предыдущего ввода
CEA: Спасибо за ответы! Напишу подробнее, как уже делал. 1. При открытии подстраницы с Text Entry, на его вход подается сначала пустая строка, буферу также присваивается пустая строка (пробовал вариант и с CLEARBUFFER в обработчике кнопки после сравнения с "asd" 2. CLEARBUFFER при открытии подстраницы не пробовал, но сильно подозреваю, что присвоить ему пустую строку, как пи сал выше, то же самое. 3. Ошибка возникает при первой "итерации", сразу после запуска. Ввода в поле еще не было. Сомнительно, что в буфере что-то уже есть сразу после перезапуска программы. 4. В отладчике смотрел сначала в общем виде, потом переключал представление в HEX. Видно, как добавляется по символу a + s + d по мере набора, в HEX видно только три байта! 5. FIND как раз срабатывает, не срабатывает прямое сравнение буфера ввода - IF ( PSW_STRING="asd") или COMPARESTRING. 6. Попробую еще поискать лишние символы, поочищать… но что то сомнительно. В порядке бреда - не могли VTPro + SG дообновлять до того, что теперь лезут всегда какие-то много байтовые кодировки, которые уже не понимает вторая серия?
Вячеслав: ЛCEA пишет: Сомнительно, что в буфере что-то уже есть сразу после перезапуска программы Не сомнительно Но дело в другом. Достаточно правильно вывести дебаг и все стало понятно. При вводе каждой новой буквы, к буферу добавляется строка целиком, а не её изменения. Вводим "а" В буфере "a" Вводим "s" В буфере уже "a"+"as"="aas" Вводим "d" В буфере "aas"+"asd"="aasasd" Итого в буфере оказалось совсем не то что хотелось длиной 6 символов.
CEA: Спасибо большое! Точно, в отладчике я фактически смотрел не содержимое буфера, а то, что туда поступало порциями из Text Entry: "a" , "as" и "asd". А буфер сделал все верно - все это сложил.
полная версия страницы