Приложения скомпилированы на компьютере со стандартным DPI. При запуске на High DPI появляется непонятный отступ справа, если окно небольшой ширины. У элементов Anchors [akLeft,akTop], но это не помогает.
И глючит заголовок окна. Фокус при наведении на элементы управления (свернуть, развернуть, закрыть) появляется на доли секунды, а затем пропадает (курсор на кнопке, а она не подсвечивается).
Плюс различные глюки VCL (не связаны с DPI), когда после hover остаются артефакты и пр.
Проверял всё на Delphi 10 Seattle.
Очень много лет писал на Delphi, пока не стал заниматься в основном вебом. Недавно скачал последнюю IDE, чтобы внести небольшие правки в старый проект. Так вот, IDE не поддерживает High DPI, весь интерфейс размыт из-за масштабирования картинки средствами ОС. Формы в получившемся приложении глючат (а там нет ничего сложного). Например, при наведении курсора на крестик (закрытие окна) элемент сразу же теряет фокус (курсор на нем, а фокуса нет). Всё это очень печально, хотя я всегда был сторонником языка и IDE в целом.
Видно, что люди уже давно стоят, а касса всё еще «свободная». Вот и интересно как они эту информацию обновляют. Если автоматически, то таких задержек по 5 минут быть не должно.
В гипермаркетах «глобус» на линии касс есть мониторы, отображающие длину очереди и рекомендующие свободные кассы. Так вот ощущение, что информация берется с потолка (свободные кассы почти всегда не лучше других). Кто-нибудь знает, как у них это устроено?
Насколько я понимаю, это из-за длинного процесса fingerprint (получение уникального id браузера/железа/пользователя), который выполняется на каждой странице в процессе оплаты (подгружаются флешки, скрипты, выполняются какие-то расчеты и пр.). Если что-то в этом процессе идет не так, то перевод не проходит, и появляется это сообщение.
Около полугода назад я увидел такое, от чего до сих пор отойти не могу. Увиденное не дает мне спокойно пользоваться Яндекс.Деньгами, ничего не могу с этим поделать. Речь о том, что после очередного перевода денег на другой кошелек я увидел следующую ошибку: «Перевод выполнен, но мы не смогли добавить запись в историю операций» (не дословно, но смысл сохранен).
А еще очень надоела ошибка, когда ищешь по всей истории («Мои операции», «Вся история», поле «Платеж, перевод или пополнение»), жмешь enter и неожиданно попадаешь на страницу «Мои операции».
А еще в эту же историю записи добавляются не сразу, а секунд через 15, что иногда сбивает с толку.
Если говорить о примере из первой главы, то на мой взгляд стало хуже. Была одна довольно маленькая функция с линейным выполнением (посмотрел на неё и сразу всё понял), а стало много мелких связанных друг с другом функций (бегаешь глазами от одной к другой). Если функция часто используется, а не один вызов на запрос, то её быстродействие существенно просядет за счет множества внутренних вызовов.
Очевидно, что нужно разбивать сложные функции на части. Но у меня часто возникает проблема из-за того, что внутренние функции очевидно не будут где-либо повторно использованы. Довольно часто это специфическая функция со специфическим набором параметров и специфическим результатом. И как её тогда называть? Использовать имя родительской функции в качестве префикса? Более того, если мы выносим код в отдельную функцию, то появляется вопрос проверки входящих параметров, который наверняка выполнялся в родительской функции. В родительской функции мы точно знали, что параметры верные, а тут получается мы или ничего не проверяем, что плохо для самостоятельности новоиспеченной функции, или в очередной раз проверяем то, что уже проверяли раньше, что негативно сказывается на быстродействии. В основном я программирую на php и там у меня с этим совсем беда, так как в языке нет локальных функций. Их наличие могло исправить ситуацию за счет того, что внутренние функции имеют локальную область видимости, а значит не должны иметь уникальные понятные имена, плюс не могут быть вызваны из вне, а значит нет смысла по несколько раз проверять параметры.
Chrome открывает страницы существенно быстрее FireFox, это очень напрягает. Всё еще сижу на FireFox, но если бы в Chrome закрытие последней вкладке не закрывало бы браузер, то уже наверное перешел бы. Наверное дело привычки, но почему я должен привыкать? Почему нельзя добавить опцию? Все расширения типа «Last Tab» работают ужасно.
Сделайте, пожалуйста, ссылку на комментарии в мобильной версии. И еще не обрезайте картинки в галереи в той же мобильной версии (лучше добавьте белые полосы, но не обрезайте головы людям).
Проблема в том, что SPF проверяет только параметр Return-Path, а не From. Пользователи же видят именно From. Так что штука практически бесполезная в контексте защиты от фишинга и нужна больше для защиты от спама ответными сообщениями об ошибках.
На самом деле проблема не только с email. Например, тип url. Значение www.ya.ru по сути неверное, но браузер может преобразовать в www.ya.ru и отправлять именно это значение (и предоставлять его скриптам).
Я имею в виду, что если делать trim при отправке формы, то как быть, например, в случае ajax (когда скрипт сам берет значение из поля)? Как быть с псевдоклассами валидации? Т. е. визуально значение одно (с пробелом), а фактически для скриптов другое?
Как-то установил на проекте тип email для всех полей, предназначенных для ввода почты. Сначала радовался (автоматическое добавление нужных символов на клавиатурах мобильных устройств), а потом вернул тип text. Почему? Потому что если случайно добавить лишний пробел (перед адресом или после), то браузеры считают значение неверным и не дают отправить форму. А ведь это происходит очень часто и вводит пользователей в заблуждение (особенно при copy-paste). В итоге, бесполезный тип без костылей на JavaScript, хотя при отправке достаточно было бы сделать trim. Возникает еще проблема с доступом к value из скрипта, но могли бы что-нибудь придумать.
beeinfo, сегодня у нас произошел аналогичный случай.
Мы иногда используем QIWI кошелек для расчета с партнерами. Утром перестали приходить SMS с кодами подтверждений, SIM-карта перестала регистрироваться в сети. Затем пришло письмо на почту от QIWI с информацией для восстановления пароля (кто-то пытался получить доступ к кошельку). Сразу поехали в офис Билайна и там узнали, что кто-то сегодня утром в Челябинске получил дубликат (оригинальная SIM-карта получена и используется в Москве). Заблокировали дубликат и получили новый. Самое интересное в том, что человек, на которого была оформлена карта, не является публичным, информацию о нем нельзя было найти где-либо в интернете. Имя и фамилию мог узнать только сотрудник Билайна по номеру телефона. В итоге, чуть не потеряли около 100 тысяч рублей, которые лежали на балансе в QIWI.
Возникает вопрос, действительно ли дело в доверенностях? Почему за последние несколько дней ситуация настолько ухудшилась? Сколько же должно быть «приближенных» мошенников, чтобы они вдруг могли заинтересоваться нами? Повторюсь, номер использовался исключительно для внутренних операций с QIWI и был зарегистрирован на человека, информацию о котором можно найти исключительно в базе Билайна.
И глючит заголовок окна. Фокус при наведении на элементы управления (свернуть, развернуть, закрыть) появляется на доли секунды, а затем пропадает (курсор на кнопке, а она не подсвечивается).
Плюс различные глюки VCL (не связаны с DPI), когда после hover остаются артефакты и пр.
Проверял всё на Delphi 10 Seattle.
А еще очень надоела ошибка, когда ищешь по всей истории («Мои операции», «Вся история», поле «Платеж, перевод или пополнение»), жмешь enter и неожиданно попадаешь на страницу «Мои операции».
А еще в эту же историю записи добавляются не сразу, а секунд через 15, что иногда сбивает с толку.
Очевидно, что нужно разбивать сложные функции на части. Но у меня часто возникает проблема из-за того, что внутренние функции очевидно не будут где-либо повторно использованы. Довольно часто это специфическая функция со специфическим набором параметров и специфическим результатом. И как её тогда называть? Использовать имя родительской функции в качестве префикса? Более того, если мы выносим код в отдельную функцию, то появляется вопрос проверки входящих параметров, который наверняка выполнялся в родительской функции. В родительской функции мы точно знали, что параметры верные, а тут получается мы или ничего не проверяем, что плохо для самостоятельности новоиспеченной функции, или в очередной раз проверяем то, что уже проверяли раньше, что негативно сказывается на быстродействии. В основном я программирую на php и там у меня с этим совсем беда, так как в языке нет локальных функций. Их наличие могло исправить ситуацию за счет того, что внутренние функции имеют локальную область видимости, а значит не должны иметь уникальные понятные имена, плюс не могут быть вызваны из вне, а значит нет смысла по несколько раз проверять параметры.
Мы иногда используем QIWI кошелек для расчета с партнерами. Утром перестали приходить SMS с кодами подтверждений, SIM-карта перестала регистрироваться в сети. Затем пришло письмо на почту от QIWI с информацией для восстановления пароля (кто-то пытался получить доступ к кошельку). Сразу поехали в офис Билайна и там узнали, что кто-то сегодня утром в Челябинске получил дубликат (оригинальная SIM-карта получена и используется в Москве). Заблокировали дубликат и получили новый. Самое интересное в том, что человек, на которого была оформлена карта, не является публичным, информацию о нем нельзя было найти где-либо в интернете. Имя и фамилию мог узнать только сотрудник Билайна по номеру телефона. В итоге, чуть не потеряли около 100 тысяч рублей, которые лежали на балансе в QIWI.
Возникает вопрос, действительно ли дело в доверенностях? Почему за последние несколько дней ситуация настолько ухудшилась? Сколько же должно быть «приближенных» мошенников, чтобы они вдруг могли заинтересоваться нами? Повторюсь, номер использовался исключительно для внутренних операций с QIWI и был зарегистрирован на человека, информацию о котором можно найти исключительно в базе Билайна.