Вас порвут, уважаемые :)

LavLav Королев
отредактировано 15:11 Раздел: FastReport Studio
Помнится, давно уже вам говорили, что пора на .NET портировать продукт и использовать его преимущества, потому как M$ неотвратимо наступает... Про WYSIWYG сейчас не стоит - до релиза 2.0 как раз сделали бы. И что в итоге? Делфи, масса неудобств с постоянно меняющейся функциональностью (в том числе в скриптовом движке) и (теперь уже затихшие) мольбы разработчиков, в большистве своем вынужденно пересаживающихся на .NET. А теперь еще раз загляните к StimulSoft'овцам! В 1.3 доделан WYSIWYG, народ пачками переходит с Crystal и ActiveReports на Stimul.. А вы цены задираете ;) Про аналогичные вашим примеры - это фигня. Вы хоть поняли, как построен StimulReport?! Предельно очевидная мысль в контексте .NET и блестяще реализована! Похожесть с FR зря вас расслабила - внутри ничего общего. Короче, люди! Если вы не возьмете руки в ноги и не зашевелитесь, то с ентим гадским дотнетом скоро пролетите, как стая рашпилей! ;)
«1

Комментарии

  • almanalman космополит
    отредактировано 15:11
    Спасибо за критический отзыв. Мы будем иметь в виду Ваше мнение.
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    Десять балов, Lav! По живому и прямо в точку! Полностью солидарен. Я ждал полгода и в итоге уже сижу на Stimul(е). А жаль...
  • отредактировано 15:11
    Рвите ;) FR3 - не только для .NET. Очень многие сидят на MSVC 6 и на net плевать хотели...
    >>Вы хоть поняли, как построен StimulReport?!
    дайте исходники - посмотрим, и может быть, поймем...
  • отредактировано September 2005
    Кстати, цены у них выше на $150. И где там 1.3? На сайте речь о 1.23.
  • MichaelMichael планета Земля
    отредактировано 15:11
    Lav написал:
    А теперь еще раз загляните к StimulSoft'овцам! В 1.3 доделан WYSIWYG, народ пачками переходит с Crystal и ActiveReports на Stimul..
    Про аналогичные вашим примеры - это фигня. Вы хоть поняли, как построен StimulReport?! Предельно очевидная мысль в контексте .NET и блестяще реализована!
    С коллегами-соотечественниками по репортам мы активно общаемся.

    Приниципы построения отчётов, действительно, несколько разные.

    Думаю, Виталик Кубекин (stimulsoft) не обидится, если я его немного процитирую:
    Lav написал:
    в нашем принцип следующий:
    происходит обход страницы, при встрече контейнера происходит вывод
    контейнера пока у него есть место куда выводить,  и так всех
    контейнеров на странице после вывода страницы сомтрим готова страница
    или нет если не готова то повторно проход по странице
    и всем контейнерам

    плюсы:

    на одной странице легко можно вести вывод данных в несколько потоков - скажем параллельно два списка

    минусы:

    достаточно тяжело делать элементарные вещи
    например сооыбтие OnManualPage (так кажется называется) реализовать почти невозмоджно
    отчет однопроходной
    итоги считаются путем подписывания объектов на соотвествующие события бендов и тюд
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    Простой пример из жизни (это частный случай, но для статистики Вам, Александр, пригодится): не большая фирма своими силами хочет перейти на качественно новый софт, естественно вопрос по ГО, какой? Парк машин довольно старый, поэтому либо писать на vb6 (как раньше) либо писать на net, но тогда обновить парк машин. Так как основная работа с БД, то на ГО ложится основная нагрузка. На выбор подействовала ценовая политика FastReport - у конкурента Stimul лицензия на физ. лицо + исходники =39$, да при оплате WebMoney скидка 25%, итого всего 29$. При этом у net большие (imho) перспективы чем у win32. Хотя затраты на обновление компьютеров будут большими. А если бы FastReport studio стоил бы столько же (причём исходники многим не нужны) выбор был бы в пользу Вас.
    Так, что в данном случае на выбор сыграл психологический фактор, но повторяю это частный случай. FastReport был "народным" продуктом (по цене) и теперь тяжело поломать стереотип, что надо платить больше. Ситуация очень напоминает события с AMD - пока была гадким утёнком на всю трубила, что её интересует только конечный пользователь, поэтому и цены "народные", и что мы видим сейчас? Бизнес. Хочется надеятся, что Ваши маркетологи, Александр, на правильном пути.

  • LavLav Королев
    отредактировано 15:11
    To AlexTZ..
    >>Очень многие сидят на MSVC 6 и на net плевать хотели...
    Вы давно работу меняли? Я не о факте смены работы, а о вакансиях на рынке труда для разработчиков ПО.
    Рынок диктует приоритетные средства разработки, причем по объективным причинам (всем здесь, наверное, ясно чего и как быстро обычно хочет заказчик).
    Можно только сказать - плюйте ;) (если, конечно, уверены в консервативности своего руководства и пожизненном нынешнем рабочем месте)
    >>Кстати, цены у них выше на $150. И где там 1.3? На сайте речь о 1.23.
    Цены выше только на корпоративный вариант, но там уже совершенно другие вопросы. Касаемо 1.3 - если интересно, то к разработчикам. Скоро выложат.

    ЗЫ
    Не воспринимайте, как "наезд". Я не абсолютизирую Stimul. Я вообще с ним еще толком не работал. Я разобрался, чего они сделали, и могу в плюсы цитаты Виталия Кубекина дописать еще целую уйму топиков, которые любой может найти в хорошей книге по .NET. Все это, действительно, в большей мере касается разработки под .NET, но последняя, черт побери, наступает! Обращением к разработчикам FR я подчеркиваю небезразличие многих к их продукту и призываю вступать в конкурентную борьбу. Ведь нам всем это не помешает, верно?! ;)
  • отредактировано 15:11
    Выскажу свое чисто субъективное мнение.
    Выпуск FastReport.Studio напоминает советские времена, когда выпуск изделия планировался за 20 лет вперед и под него готовилась инфраструктура, поставщики, сбыт и т.п. Примеры: советский видеомагнитофон( 1970-е годы), или персональный компьютер ( 1980-е). К тому времени, как продукт запускался в серию, он морально устаревал и поставлялся только на те предприятия, которым был запланирован, и которые, используя данную технику, не могли выдерживать конкурентную борьбу (качество телепередач, скорость расчетов и т.п.) Я о том, что разработчики, используя данную технологию отчетов, со временем будут проигрывать тем, кто использует отчеты на нетовских движках. Предполагаю, что это время наступит при использовании новых операционок и SQL сервера с поддержкой .net, которые на подходе. К разработкам отчетов под Windows-приложения мое мнение не относится.
  • MichaelMichael планета Земля
    отредактировано 15:11
    Как бы вам всем ответить?
    В качестве примера можно привести Кристал - он ненативный, однако интегрирован в среду разработки на порядок лучше, чем все "нативные" решения. В чем, по-вашему, преимущества нативных решений? В наличии исходников? В расширяемости? По скорости и функциональности они сейчас в достаточно сильном проигрыше.
  • отредактировано 15:11
    написал:
    В чем, по-вашему, преимущества нативных решений? В наличии исходников? В расширяемости? По скорости и функциональности они сейчас в достаточно сильном проигрыше.
    Я предлагаю изменить угол зрения и посмотреть с другой стороны.
    Вместо множества скриптовых языков в отчетности с нетовским движком можно использовать .Net CLR. Поскольку сборки .Net являются заранее скомпилированными, то мы получим существенное увеличение производительности.
    В Юконе вообще реализована интеграция .Net CLR и ядра SQL Server. Следовательно, в .net можно вынести всю математику, лексический и синтаксический разбор и т.п., т.е. все, для чего TSQL не предназначен
  • LavLav Королев
    отредактировано 15:11
    написал:
    нативный... ненативный...
    А куда катится ненативный Delphi со своими Enterprise Core Objects?! Судя по всему, скоро он превратится только лишь в классовую надстройку над классами же .NET. И все это - ради Kylix?! А M$ тем временем заменяет свой API на объектно-ориентированный, и становится очевидно, что скоро .NET будет основным программным интерфейсом Windows.

    .. как бы не начать священную войну ;)
    ;)

    и ваще, я люблю борланд! ;)
  • almanalman космополит
    отредактировано 15:11
    Кстати, вопрос к отписавшимся.
    Может быть раскритикуете здесь обёртку над нетовской DataTable, которая поставляется в демках? Было бы очень интересно послушать.

  • almanalman космополит
    отредактировано 15:11
    vlad_galaxy написал:
    Вместо множества скриптовых языков в отчетности с нетовским движком можно использовать .Net CLR. Поскольку сборки .Net являются заранее скомпилированными, то мы получим существенное увеличение производительности.
    Конечно, Ваши аргументы верны и Вы прав.

    Однако, студия уже давно умеет выполнять С# код, посредством события OnUserFunction().

    Вместе со студией поставляется пример UserFunctionExample, в котором число переводится в строку прописью. Таким образом, особо критичные места студия умеет выполнять в С#, впрочем, как и в C++ и в других языках/средах.
  • отредактировано 15:11
    написал:
    Может быть раскритикуете здесь обёртку над нетовской DataTable, которая поставляется в демках? Было бы очень интересно послушать.
    Дело не в критике, а в том, что в текущей версии пока не реализован интерфейс IComparer для сравнения строк таблицы. Плюс пока нет учета релэйшенов. Это затрудняет коммерческое использование продукта. Может, я ошибаюсь, не зная внутренней структуры, но могу предположить, что где-то сидит боязнь отказаться от TField и TTable. В идеале нужно вообще убрать юзание DB.PAS и т.п. во ВСЕХ модулях FastReport.Studio.
  • отредактировано 15:11
    DB.pas нужен, т.к. юзается TADOTable/TADOQuery. Про релейшены и компарер пока ничего не знаем ;)
  • отредактировано 15:11
    написал:
    Про релейшены и компарер пока ничего не знаем
    Я попытался сказать, чего, на мой взгляд, не хватает обёртке над нетовской DataTable. Т.е. прикладнику, например, придется самому реализовывать в дотнете технологию сортировки. Не скажу, что задача чересчур сложная, но потребуются некоторые ресурсы, которые придется снимать с каждого прикладнго проекта. По поводу ADO: я бы вынес его за рамки ядра на уровень вышеупомянутой нетовской DataTable.
    Для уточнения - я говорю только о проектах, исполняемых в .Net CLR.
  • отредактировано 15:11
    vc6, foxpro, "...нативный не нативный...", db.PAS...
    Все это продожает говорить о том, что fr inc не уловила смысл ветки этого форума...

    "...Очень многие сидят на MSVC 6 и на net плевать хотели... "
    "...дайте исходники - посмотрим, и может быть, поймем..."
    Это опять о том, что ни Александр, ни Михаил не уделили внимание названию ветки этого форума.

    Почему:
    1. пользователи FR говорят о fr.net очень давно, а компания только игнорирует эти разговоры?
    2. сейчас, когда говорят напрямую "вас порвут", опять звучат слова о том, что есть другие рынки, которые интересны компании?
    3. пользователи (в т.ч. бывшие) пытаются говорить о том, что за .net будущее (ближайшее), а у многих это уже реальность, а FR.NET нету?.. есть Студия... которая, как и fr3, многим кажется неадекватными затратами и вложениями fr inc
    4. до сих пор в fr inc нет понимания .net (и многообразия источников данных в .net)

    наша компания работает под .net ...
    fr.net нам уже не интересен. мы уверены, что fr inc не сможет его сделать, если не изменит отношение к .net.

    мы используем StimulReport более 6 месяцев. это несравниваемый с FR продукт. это другое. это как QR1 с FR3 сравнивать.

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

    но, если это будет через пару лет и с таким отношением к .net - fr inc рискует быть "порваной" конкурентами.
  • отредактировано 15:11
    >Почему:
    А Вы посмотрите, сколько пользователей на этой ветке форума. Также загляните на соседние ветки.
    И все же, я не услышал ответа, чем нативное .net решение лучше, чем win32 dll. Кстати, а чем вы в Stimul диаграммы строите?
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    To AlexTZ:
    написал:
      Вы посмотрите, сколько пользователей на этой ветке форума. Также загляните на соседние ветки.
    Это говорит о том, что многие из тех, кто перешёл-начал писать на net, пользуются другим продуктом (впрочем, ещё очень мало времени прошло со дня выхода FastReport Studio)
    написал:
      И все же, я не услышал ответа, чем нативное .net решение лучше, чем win32 dll. Кстати, а чем вы в Stimul диаграммы строите?
    Сравнение не .net решения vs win32, а Fast vs Stimul.

    Минусы (навскидку):
    1. Использование своих скриптовых языков. Я не спорю, реализация может быть чудесной, но необходимо время на изучение + практика. В своё время намучился с кристалом. Так как пользуюсь редко, каждый раз, как припечёт, приходится изобретать велосипед. Меня просто поразило решение использовать в Stimul в качестве скрипта полноценный .net, а главное насколько это удобно и упрощает жизнь! Плюс возможность использовать в проекте отчёт в виде Xml, dll или просто кода.
    2. Как писал vlad_galaxy: “А как работать со сложным датасетом, имеющим несколько таблиц и DataRelations?”, то есть не полностью реализована работа с датасетом.
    3. Мне не нравится использование в одном проекте разных технологий, таких как com и net. Как писал Michael: “В качестве примера можно привести Кристал - он ненативный, однако интегрирован в среду разработки на порядок лучше, чем все "нативные" решения”, но, кто сказал, что разработчики в восторге от кристала? Лично я был вынужден им пользоваться на vb6, не было альтернативы, такой как у Delphi FastReport, но я им сыт по горло. В общем я сторонник простоты - .net так .net, или com так com, легче жить как разработчикам так и сопровождающим.

    Плюсы:
    1. Ресурсы. Я немного поэкспериментировал: отчёт содержал около 50 TfrxMemoView (в Stimul - Текст), создавалось около 1 тысячи страниц (точно не помню). Fast справился ~ за минуту-полторы и “скушал” около 50 или 70 MB ОЗУ, Stimul ~ 4-5 минут и ~ 500 MB ОЗУ (по диспетчеру задач, но можно ли ему верить?).
    2. Реализация построения диаграмм. Я ещё не спрашивал Виталия Кубекина, но думаю, что в Stimul это скоро появится.

    Проанализировав ситуацию на рынке, можно прийти к следующему выводу: если считать .net более перспективной технологией, и, следовательно, более высокооплачиваемой, то плюс №1 отходит на второстепенный план, разработчики пишущие новые проекты на .net, по возможности будут подбирать и .net инструменты, да и наверняка многие заказчики будут предъявлять такие требования.

    Ещё: вам нужно было реализовать поддержку ado Recordset VB6, он продолжает оставаться популярным языком, достаточно зайти на сайт Релиб.






  • almanalman космополит
    отредактировано September 2005
    ATechnology написал:
    4. до сих пор в fr inc нет понимания .net (и многообразия источников данных в .net)
    Всё ли многообразие источников данных .NET использует объект DataTable?
    Могу утверждать, что FastReport умеет работать .NET с объектом DataTable.
    Мне кажется, что Вас ввел в заблуждение тот факт, что во всех демонстрационных отчётах используется встроенный ADO движок. На самом деле, в исходниках демок есть простейший пример, как сделать сделать DataTable прозрачной для FastReport.

    Или Вы желаете чтобы все обёртки между COM и .NET были вынесены в отдельную strong name библиотеку и распртранялись вместе со Студией?

    Если я неправильно понял, то, пожалуйста, объясните в чём я ошибаюсь.
  • almanalman космополит
    отредактировано September 2005
    vlad_galaxy написал:
    Я попытался сказать, чего, на мой взгляд, не хватает обёртке над нетовской DataTable. Т.е. прикладнику, например,  придется самому реализовывать в дотнете технологию сортировки. Не скажу, что задача чересчур сложная, но потребуются некоторые ресурсы, которые придется снимать с каждого прикладнго проекта.

    В действительности - немного не так.

    Обёртка, назвовём её для простоты FrxDataTable, наследована от DataTable, при этом сохраняет все возможности оригинального DataTable.NET.

    Прозрачность DataTable по отношению к FastReport достигнута за счёт добавления свойства TfrxUserDataSet к DataTable и пары обработчиков событий. При этом, добавление столбцов в DataSet автоматически добавит столбцы в TfrxUserDataSet (.NET действительно рулит).

    Выборка данных в отчёт берётся непосредственно из DataTable. В этом случае встроенные в FastReport движки баз данных не задействованы.

    Хочу ещё раз обратить Ваше внимание - прозрачность DataTable по отношению к FastReport сохраняет доступными все свойства таблицы.
    Таким образов DataSet.NET может включать в себя одну или несколько FrxDataSet без потери функциональности.
    vlad_galaxy написал:
    По поводу ADO: я бы вынес его за рамки ядра на уровень вышеупомянутой нетовской DataTable.

    Я бы тоже так поступил, но сейчас нам приходится находить компромисс между
    встраиваемыми решениями и standalone solutions.
    Скорее всего, в будущем мы вынесем движки баз данных из ядра, но это дело времени.
  • almanalman космополит
    отредактировано September 2005
    ovs2 написал:
    2. Как писал vlad_galaxy: “А как работать со сложным датасетом, имеющим несколько таблиц и DataRelations?”, то есть не полностью реализована работа с датасетом.

    Надеюсь, предыдущий пост хорошо объясняет принцип работы FastReport c DataSet.NET.
    ovs2 написал:
    3. Мне не нравится использование в одном проекте разных технологий, таких как com и net. 

    Пожалуй, это наиболее веский аргумент из всех вышеперчисленных.
    ovs2 написал:
    В общем я сторонник простоты - .net так .net, или com так com, легче жить как разработчикам так и сопровождающим.

    Не будем спорить о простоте сопровождения ;)
    Что же касается простоты, то, по большому счёту, с точки зрения прикладного программиста, - и .net и СОМ объекты - всего лишь интерфейсы. Правильно?

    Наша задача - сделать эти интерфейсы наиболее удобными и прозрачными для использования во всех средах разработки и языках программирования.
  • отредактировано 15:11
    "...Всё ли многообразие источников данных .NET использует объект DataTable?
    Могу утверждать, что FastReport умеет работать .NET с объектом DataTable.
    ..."

    1. DataTable... (нет связей в fr studio)
    2. Bussiness Objects
    3. DataView
    4. Enumerable Sources
    5. xml datasources
    5. доступ к данным (oledb, odbc и пр.) прям из генератора
    (то, что всегда было интересным в fr2, fr3...)


    "...>Почему:
    А Вы посмотрите, сколько пользователей на этой ветке форума. Также загляните на соседние ветки.
    И все же, я не услышал ответа, чем нативное .net решение лучше, чем win32 dll. Кстати, а чем вы в Stimul диаграммы строите?
    ..."

    и это весь ответ? больше сказать нечего?

    чартов до сих пор нет в SR, говорят, что работы ведутся по созданию собственных (уровня Dundas).
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    To alman:
    написал:
    Не будем спорить о простоте сопровождения
    Что же касается простоты, то, по большому счёту, с точки зрения прикладного программиста, - и .net и СОМ объекты - всего лишь интерфейсы. Правильно?
    Вы "жарились" с Crustal Report 9.22? ;) Думаю, что да. Десятки dll, одни регистрируются нормально в win98, другие нет, в XP и win 2000 - по другому, а чего стоит usp10.dll? На сайте кристала пишут, что это проблема Microsoft, но в итоге все эти проблемы ложатся на кого? Так же не одинаково ведут себя и .net приложения под win98 и nt.
    Вы правы, спорить не будем, Вы просили указать недостатки (на наш взгляд) - мы указываем.
  • отредактировано 15:11
    написал:
    написал:
    QUOTE (ovs2 @ Sep 24 2005, 08:58 AM)
    2. Как писал vlad_galaxy: “А как работать со сложным датасетом, имеющим несколько таблиц и DataRelations?”, то есть не полностью реализована работа с датасетом.
    Надеюсь, предыдущий пост хорошо объясняет принцип работы FastReport c DataSet.NET.
    Да, для получения данных из ОДНОЙ плоской таблице такой подход применим. НО для получения отчетов Master-Detail и т.п. необходимо кодирование на уровне FrxDataTable.

    Присоединяюсь к ovs2 и добавляю замечания
    1. FrxCOM живет в однопоточной комнате, поэтому сложно сформировать отчет на сервере для публикации (сложность реализации устойчивой работы в 3х уровневой архитектуре превысила разумные пределы)
    2. дизайнер не может быть встроен в контейнер (например, типа TabControl), который де-факто стал стандартом для Windows Forms приложений.

    Возможно, из-за сложности в реализации этих пунктов, FR INC. и обращает внимание посетителей данного топика на количество пользователей в соседних ветках.

    Предварительные Выводы (за пять с половиной месяцев ):
    1.FastReport.Studio для .Net ограниченивается использованием в разовых заказных проектах для мелких заказчиков.
    2. Для использования в больших проектах необходима отдельная группа разработчиков для интеграции FastReport.Studio с основным проектом. (Возможна неудача из-за замечания №2)
  • отредактировано 15:11
    >1.FastReport.Studio для .Net ограниченивается использованием в разовых заказных проектах для мелких заказчиков.

    В данном аспекте FR.com ничем не хуже Crystal. Взгляните на разовые проекты с использованием Crystal.

    >2. Для использования в больших проектах необходима отдельная группа разработчиков для интеграции FastReport.Studio с основным проектом. (Возможна неудача из-за замечания №2)

    Дизайнер FR никогда (с самой первой версии FR) не мог быть встроен в какой-либо контейнер. Может, для Вас это важно, но тысячи наших пользователей так не считают.
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    Вопрос к AlexTZ: а на какой рынок Вы сами позиционируете FastReport Studio?
  • отредактировано 15:11
    "...Вопрос к AlexTZ: а на какой рынок Вы сами позиционируете FastReport Studio?.."

    да! очень интересный вопрос!
    - кто является целевой аудиторией?
    - кому может быть интересен этот продукт?
    - кто готов создавать "отдел интеграции продуктов с FR Studio"?
    - ...
    - "кто Слабое звено"?
  • MichaelMichael планета Земля
    отредактировано 15:11
    ATechnology написал:
    - кто является целевой аудиторией?
    a) программисты VisualStudio, PowerBuilder, Visual FoxPro, etc.
    ;) EndUsers
    ATechnology написал:
    - кому может быть интересен этот продукт?

    Сами удивляемся! ;)
    ATechnology написал:
    - кто готов создавать "отдел интеграции продуктов с FR Studio"?

    Ну тут уж вы загнули. Или где-то есть "отдел интеграции продуктов с RaveReports" или "отдел интеграции продуктов с CrystalReports"?
    Какой-то "сферический конь в абсолютном вакууме" - обсуждение на пустом месте.
    ATechnology написал:
    - "кто Слабое звено"?
    ? ;)

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

    Видимо, было не совсем верным решением обсуждение студии в топиках .Net, поскольку диапазон использования FR Studio всё же несколько шире.
  • ovs2ovs2 Днепропетровск, Украина
    отредактировано 15:11
    написал:
    С другой стороны - радостно, что бета продукта уже вызывает такой резонанс. Наши пользователи уже ходят вокруг, оценивают возможности, устраивают бенчмаркинг, предлагают нововведения, советуют, активно используют и т.п. Т.е. со студией мы не промахнулись.
    Пока ещё ходят (кстати заметьте, бесплатно, хотя продукт коммерческий) и надеются на взаимопонимание. Смотрю глазами потребиля, реально за studio я бы отдал: цена на вашем сайте / 10, исходники мне не нужны. Хоть завтра. Не из-за необходимости (обхожусь же как то).

Оставить комментарий

Многофункциональный текстовый редактор. Чтобы отредактировать стиль параграфа, нажмите TAB, чтобы перейти к меню абзаца. Там вы можете выбрать стиль. По умолчанию не выбран ни один стиль. Когда вы выберете текст, появится встроенное меню форматирования. Нажмите TAB, чтобы войти в него. Некоторые элементы, такие как многофункциональные вставки ссылок, картинок, индикаторов загрузки и сообщений об ошибок могут быть вставлены в редактор. Вы можете перемещаться по ним, используя стрелки внутри редактора и удалять с помощью клавиш delete или backspace.