Об этом надо ещё догадаться.
Чтобы зайти без смены пароля надо:
1) зайти на хабр
2) нажать на вход
3) авторизоваться на tmtm
4) вернуться на хабр
5) нажать на вход
Кстати, вы считаете пароли длинной в 15 символом со спецсимволами и разными регистрами в нём, но без цифр, слабым?
Я как-то не вижу смысла его менять, ибо помню его наизусть. А новый — ещё надо будет запоминать.
Честно говоря, из-за глюка с задержкой авторизации думал, что меня не пускают именно из-за пароля. И уже собирался ругаться с поддержкой )
Авторизация на Хабре фантастически слоупочит. После авторизации на TM ID проходит минут 10 перед тем, как хабр отреагирует хоть как-то. 1й раз я оказался залогинен на хабре минут через 10 после логина, 2й — через 5 минут вместо «войти» показалась кнопка «войти чемез tmid», по нажатию которой Хабр обновился, но уже залогиненным.
Точно не скажу, конкретно с контекстом принтера bitblt я не использовал. В любом случае, непонятно, что им мешало сделать так, как это реализовано в Stream: разные виды потоков могут не поддерживать запись или произвольное чтение, но api есть для всего, + набор флагов, позволяющий проверить возможности конкретного потока не проверяя его класс.
Graphics в случае принтера рисуется в векторе. Там нельзя просто так взять, и использовать растровый битмап. И на кой хрен там буферизация-то? Каждая страница отрисовывается 1 раз в специальном классе…
Если я верно помню, с контекста Graphics можно читать всегда. Вызываете берёте getHdc, получаете хэндл контекста и используете WinAPI.
Тут возникает встречный вопрос: зачем нужна эта высокоуровневая абстракция, если всё равно приходится спускаться вниз на конкретную реализацию? А вдруг я захочу нарисовать тоже самое именно на контексте принтера? Имхо, костыль тут как раз FromBitmap. Впрочем, и вызов bitblt тут костыль… И за это System.Drawing мне и не нравится — без костылей не обойтись.
Да не было там битмаба, там был Graphics юзерконтрола и включённая буферизация у него же ) То есть, я тупо рисовал на контроле в событии отрисовки. bitblt делал для эко контекста из самого в себя, нехватающее дорисовывал. В принципе, это даже работало и нормально выглядело.
> Это как?
А вот так ) Значения именованных цветов не совпадали с реальностью — ис того, что помню darkgray светлее чем gray.
> Вам надо картинки рисовать или дёргать куски с одного Graphics на другой?
Таки надо было дёргать куски Graphics. Делал велоконтрол для отображения древовидной структуры. Нужно было при открытии/закрытии структуры сдвигать часть изображения. Пришлось дёргать bitblt (вот в эту трубу, похоже, вся переносимость на Mono и улетает). Двойная буферизация — средствами WinForms.
Что характерно, с этой задачей bitblt превосходно справлялся: достаточно было просто передать ему хэнд контекста из Graphics.
А уж рисовать точки прямоугольниками — это вообще нечто.
На момент 4х лет назад System.Drawing был написан осьминогами. Цвета перепутаны, точку без дополнительного гемора не нарисовать, аналога bitblt не было вообще, индексированные палитры не поддерживались. Сейчас не знаю.
Ненене, не поймите неправильно, я тоже не медик )
Я писал вот к этому:
> клетки слоями накладываешь а организм сам капилляры и вены строит в ней…
Повреждения печени организм сам может неплохо регенерировать, а цирроз, насколько я знаю, поражение всего органа, а не его частей. Так что тут только полная замена…
Мы в это ветке про операционку, вообще-то, говорим. И, надо отдать должное, они таки работали. Играл я в старые игрушки в этом режиме, написанны под Win95/98, о запуске которых в Win2k даже и речи не шло.
Забывай, не забывай, но ничего противоречащего моему высказыванию вы не написали.
В WinXP по сравнению с Win2k, помимо прочего, была улучшена безопасность учётных записей пользователей и появились режимы совместимости.
Это операция не имеет смысла: печень — единственный огран человека, способный самовостанавливаться. Буквально — из небольшого фрагмента. Практикуются даже операции, когда пересаживается половина донорского ограна.
Возможно, поэтому для экспериментов и выбрали именно печень.
Не сталкивался я на практике с расчётными финансовыми задачами.
В Objective-C для отображения цен использую NSDecimalNumber потому как его для этих целей использует iOS SDK.
Но это таки тип с плавающей точкой, пусть и способен хранить до 38 значимых цифр, и ничего большего чем просто хранение цены с ним делать всё равно не стоит.
Если бы мне пришлось делать какие-то расчётные операции — я бы поискал реализацию длинной арифметики на C и использовал бы её. Из минусов — большое потребление памяти и низкое быстродействие, в сравнении со стандартными типами. Из плюсов — максимальное хранимое значение упирается только в объём доступной оперативной памяти.
В точных операциях (в том числе и фанансовых) нельзя использовать типы с плавающими точками из-за их ограниченной точности. Даже строка лучше в этой ситуации. В идеале — длинная арифметика. BigDecimal, как я понимаю (java я не знаю) — это оно и есть.
Чтобы зайти без смены пароля надо:
1) зайти на хабр
2) нажать на вход
3) авторизоваться на tmtm
4) вернуться на хабр
5) нажать на вход
Я как-то не вижу смысла его менять, ибо помню его наизусть. А новый — ещё надо будет запоминать.
Честно говоря, из-за глюка с задержкой авторизации думал, что меня не пускают именно из-за пароля. И уже собирался ругаться с поддержкой )
Если я верно помню, с контекста Graphics можно читать всегда. Вызываете берёте getHdc, получаете хэндл контекста и используете WinAPI.
А вот так ) Значения именованных цветов не совпадали с реальностью — ис того, что помню darkgray светлее чем gray.
> Вам надо картинки рисовать или дёргать куски с одного Graphics на другой?
Таки надо было дёргать куски Graphics. Делал велоконтрол для отображения древовидной структуры. Нужно было при открытии/закрытии структуры сдвигать часть изображения. Пришлось дёргать bitblt (вот в эту трубу, похоже, вся переносимость на Mono и улетает). Двойная буферизация — средствами WinForms.
Что характерно, с этой задачей bitblt превосходно справлялся: достаточно было просто передать ему хэнд контекста из Graphics.
А уж рисовать точки прямоугольниками — это вообще нечто.
Я писал вот к этому:
> клетки слоями накладываешь а организм сам капилляры и вены строит в ней…
Повреждения печени организм сам может неплохо регенерировать, а цирроз, насколько я знаю, поражение всего органа, а не его частей. Так что тут только полная замена…
В WinXP по сравнению с Win2k, помимо прочего, была улучшена безопасность учётных записей пользователей и появились режимы совместимости.
Возможно, поэтому для экспериментов и выбрали именно печень.
В Objective-C для отображения цен использую NSDecimalNumber потому как его для этих целей использует iOS SDK.
Но это таки тип с плавающей точкой, пусть и способен хранить до 38 значимых цифр, и ничего большего чем просто хранение цены с ним делать всё равно не стоит.
Если бы мне пришлось делать какие-то расчётные операции — я бы поискал реализацию длинной арифметики на C и использовал бы её. Из минусов — большое потребление памяти и низкое быстродействие, в сравнении со стандартными типами. Из плюсов — максимальное хранимое значение упирается только в объём доступной оперативной памяти.