Программирование, т. 8

[Rooster]

А в документе вариант картинку послать?

[Veers]

А в документе вариант картинку послать?

Ебать, попадались письма с вордовскими документами -> внутри картинка -> картинка это фото с бумаги -> бумага напечатана пару этажей ниже

[suez]

 

Новый редизайн гмаила на десктопах (который по ходу тупо реюзает "наработки" из Inbox) просто взял и выебал все большие картинки с aspect ratio больше чем 1:1.66. То есть допустим имеется картинка оригинального размера 1000*5000 (экспорт рендера какой-нибудь сложной таблицы с чартами, которую в обычной email html таблице не сделать руками). Эта картинка еще до попадания к клиенту режется до 200*1000 и потом на экране красуется такая вот пиздюленка, вместо желаемых 600*3000 допустим (600-660пикселей это индустрийный стандарт для ширины емейлов чтобы на всех клиентах работало).

 

И вот просто нихуя с этим не сделать, никаких параметров не передать, ничего. Емейл клиент сам все решает за тебя, как ему там чо оптимизировать. Такого больше нигде нет. В старом гмейле, яндексе, любых и аутлуках и прочем не имеется ограничений по размерам (в пикселях) картинок, там есть только общие ограничения по размером прикрепленных ассетов и подобным хуйням касаемо метробайтов.

 

Единственная идея в голове, это мать его резать экспортируемые картинки на куски с лимитом в 1к пикселей и потом их ставить 1 под другим, но это звучит как адский костыль, для которого надо будет менять код в нескольких местах и не факт что это будет работать как надо, учитывая что картинки грузятся асинхронно в емейлах, то есть юзер будет наблюдать за рандомной загрузкой кусков всяких таблиц и высоких чартов.

пакуй картинки в архив )

 

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

Изменено 13 августа 2018 пользователем suez

[Kant]

Ребята, я же не посвящаю вас в тонкости Role Tailroed Cleint-а навижена и языка C\AL. Здесь как раз ценится использование "встроенных гавно-возможностей Либы/фреймворка/тулкита/АПИ". Здесь важна работа продукта в любых случаях используя по максимуму говно возможности навижена, без использования нестандартизованых либ. Дотнет либы форм, стандартизованые и я могу их использовать.

 

В System.Windows.Forms.Form есть методы которые мне могут помочь, единственная загвоздка, мое непонимание как гетнуть эти формы. Вопрос в этом заключался. А вы копаете нахуя-нахуя, ну вот ебанулся я, шо поделать(((

 

В каких ситуациях мне нужно? Для автоматизации тестирования как минимум, с помощью C\AL я отлавливаю все ошибки, вроде бы просто.

 

Для меня важность модальности в том, чтобы отловить ошибку с родительского обьекта, форма которая откроется должна быть привязанна к родительской. Иначе NAVISION не отловит ошибку, так как она будет идти с другого обьекта.

 

 

Почему все через залупу?

 

ДА ПОТОМУ ЧТО СРЕДСТВА ДЛЯ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ В НАВИЖЕНЕ НА ЕБУЧЕМ ЗАЧАТОЧНОМ УРОВНЕ!!!!1111111

нихуя я так и не понял

 

и тем более я не понял, что мешает тебе делать

foreach (Form form in Application.OpenedForms)

{

// ебись конем с form

}

[DDamager]

купил мак по работе чтобы нормально подевелопить версию под мак. это пиздец. хз как люди с этим живут

[madvlaydin]

ты просто не гей

[Cantona.Eric]

ты просто гей

fxd

[TheDeadSkin]

купил мак по работе чтобы нормально подевелопить версию под мак. это пиздец. хз как люди с этим живут

а что ты хотел от мобильной ОС с дизайном в ущерб функционалу

[SKYnv]

^^^ ловите наркомана!

[choojoykin]

гайз подскажите

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

приложение работает в параллельных потоках где каждый поток должен засторить из данных значение, которон он получил, конкретно под себя в этом методе глубоко в недрах приложения

ps пробрасывать выше это значение не могу

pps есть вариант сторить значение в бд с привязкой по уникальному значению, которое знает поток

[Rooster]

Возьми редакс

[SKYnv]

гайз подскажите

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

приложение работает в параллельных потоках где каждый поток должен засторить из данных значение, которон он получил, конкретно под себя в этом методе глубоко в недрах приложения

ps пробрасывать выше это значение не могу

pps есть вариант сторить значение в бд с привязкой по уникальному значению, которое знает поток

sqlite (in-memory)

Изменено 13 августа 2018 пользователем SKYnv

[Kant]

слишком абстрактно что-то ты описал

хоть язык какой

 

и не совсем понятно, если значение меняется постоянно в других потоках, зачем его хранить?

тебе не надо актуальное?

[Dimidrol1]

 

купил мак по работе чтобы нормально подевелопить версию под мак. это пиздец. хз как люди с этим живут

а что ты хотел от мобильной ОС с дизайном в ущерб функционалу

 

чево

[DIMAN123456789]

Новый редизайн гмаила на десктопах (который по ходу тупо реюзает "наработки" из Inbox) просто взял и выебал все большие картинки с aspect ratio больше чем 1:1.66. То есть допустим имеется картинка оригинального размера 1000*5000 (экспорт рендера какой-нибудь сложной таблицы с чартами, которую в обычной email html таблице не сделать руками). Эта картинка еще до попадания к клиенту режется до 200*1000 и потом на экране красуется такая вот пиздюленка, вместо желаемых 600*3000 допустим (600-660пикселей это индустрийный стандарт для ширины емейлов чтобы на всех клиентах работало).

 

И вот просто нихуя с этим не сделать, никаких параметров не передать, ничего. Емейл клиент сам все решает за тебя, как ему там чо оптимизировать. Такого больше нигде нет. В старом гмейле, яндексе, любых и аутлуках и прочем не имеется ограничений по размерам (в пикселях) картинок, там есть только общие ограничения по размером прикрепленных ассетов и подобным хуйням касаемо метробайтов.

 

Единственная идея в голове, это мать его резать экспортируемые картинки на куски с лимитом в 1к пикселей и потом их ставить 1 под другим, но это звучит как адский костыль, для которого надо будет менять код в нескольких местах и не факт что это будет работать как надо, учитывая что картинки грузятся асинхронно в емейлах, то есть юзер будет наблюдать за рандомной загрузкой кусков всяких таблиц и высоких чартов.

Вот и ты докатился до кровавого ынтерпрайса. Аттач как cid или вставляй картинки как base64 и будет тебе счастье

Изменено 13 августа 2018 пользователем DIMAN123456789

[TheDeadSkin]

 

 

купил мак по работе чтобы нормально подевелопить версию под мак. это пиздец. хз как люди с этим живут

а что ты хотел от мобильной ОС с дизайном в ущерб функционалу

 

чево

 

ОС где я имея 10.10 не могу нормально обновиться до 10.12, а только до 10.13 = ебучая мобильная ось

[choojoykin]

слишком абстрактно что-то ты описал

хоть язык какой

 

и не совсем понятно, если значение меняется постоянно в других потоках, зачем его хранить?

тебе не надо актуальное?

да джавка епт

потоки не меняют данные друг другу

каждый поток считай получает данные из метода. метод принимает разные параметры от потоков

грубо говоря каждый поток получает клиента у которого есть баланс

вот этот счет куда то надо и как то засторить так чтобы поток потом изменил баланс  дальше в другом месте и дальше в другом месте считай баланс вернуть на место

[Kant]

 

слишком абстрактно что-то ты описал

хоть язык какой

 

и не совсем понятно, если значение меняется постоянно в других потоках, зачем его хранить?

тебе не надо актуальное?

да джавка епт

потоки не меняют данные друг другу

каждый поток считай получает данные из метода. метод принимает разные параметры от потоков

грубо говоря каждый поток получает клиента у которого есть баланс

вот этот счет куда то надо и как то засторить так чтобы поток потом изменил баланс  дальше в другом месте и дальше в другом месте считай баланс вернуть на место

 

https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html

 

?

 

хотя обычно такое делается просто запросом заново, мало ли что поменялось

[choojoykin]

 

 

слишком абстрактно что-то ты описал

хоть язык какой

 

и не совсем понятно, если значение меняется постоянно в других потоках, зачем его хранить?

тебе не надо актуальное?

да джавка епт

потоки не меняют данные друг другу

каждый поток считай получает данные из метода. метод принимает разные параметры от потоков

грубо говоря каждый поток получает клиента у которого есть баланс

вот этот счет куда то надо и как то засторить так чтобы поток потом изменил баланс  дальше в другом месте и дальше в другом месте считай баланс вернуть на место

 

https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html

 

?

 

хотя обычно такое делается просто запросом заново, мало ли что поменялось

 

про потоки ты не совсем понял. я имел ввиду что все делается параллельно в этом плане

грубо говоря тебе нужно уметь отменять транзакцию как в БД запросах с транзакциями. только не когда в рамках одной транзакции в БД и в одном запросе. а в другом участке кода приложения

[suez]

 

Новый редизайн гмаила на десктопах (который по ходу тупо реюзает "наработки" из Inbox) просто взял и выебал все большие картинки с aspect ratio больше чем 1:1.66. То есть допустим имеется картинка оригинального размера 1000*5000 (экспорт рендера какой-нибудь сложной таблицы с чартами, которую в обычной email html таблице не сделать руками). Эта картинка еще до попадания к клиенту режется до 200*1000 и потом на экране красуется такая вот пиздюленка, вместо желаемых 600*3000 допустим (600-660пикселей это индустрийный стандарт для ширины емейлов чтобы на всех клиентах работало).

 

И вот просто нихуя с этим не сделать, никаких параметров не передать, ничего. Емейл клиент сам все решает за тебя, как ему там чо оптимизировать. Такого больше нигде нет. В старом гмейле, яндексе, любых и аутлуках и прочем не имеется ограничений по размерам (в пикселях) картинок, там есть только общие ограничения по размером прикрепленных ассетов и подобным хуйням касаемо метробайтов.

 

Единственная идея в голове, это мать его резать экспортируемые картинки на куски с лимитом в 1к пикселей и потом их ставить 1 под другим, но это звучит как адский костыль, для которого надо будет менять код в нескольких местах и не факт что это будет работать как надо, учитывая что картинки грузятся асинхронно в емейлах, то есть юзер будет наблюдать за рандомной загрузкой кусков всяких таблиц и высоких чартов.

Вот и ты докатился до кровавого ынтерпрайса. Аттач как cid или вставляй картинки как base64 и будет тебе счастье

 

Они base64 само собой, я этот генератор емейлов еще 2 года назад запилил и с тех пор все идеально работало, посылая емейлы с десятками чартов внутри. Суть в том что новый гмайл сам делает оптимизацию своими силами, уменьшая картинку по пиксельным размером. Ровным счетом нихуя не сделать.