Процедура не совсем понятна.

Dilma,
1)
Точно так же непонятно чем. В вышеприведенном примере четыре прямолинейных связи (2 горизонтальных: от onClick Button-ов к точкам 1 ссылок, и 2 вертикальных: от точек 2 ссылок к Text Edit-ов) восстановить можно однозначно. Так вот, утверждение состоит в том, что они БЫЛИ.

2) Местоположение RES-файла не очень предсказуемо. И это неправильно. При компиляции в режиме Ctrl+D он лежит в папке Compiler\, а не Elements\Code\ (надеюсь, я правильно понимаю термин "папка проекта"). Более того, после этой операции, первая компиляция другого проекта (он не в режиме Ctrl+D) берет предыдущий RES-файл (который лежит в папке Compiler), и правильная прога начинает просто неправильно работать. При второй компиляции - уже все нормально.

3)
Откройте мне, тупому, что такое указатель на на класс .
Локализацию в памяти имеют экземпляры класса и методы класса. Указателя на класс не бывает. По крайней мере, я до сих пор так думал. А в полях элемента MultiElementEx у нас уже лежит указатель на элемент EditMultiEx из текущего экземпляр класса (FChild), и на конструктор класса (FOnCreate - хитрым способом правда, но, как я понимаю, это лишь следствие хитромудрости Object Pascal). А в элементе EditMultiEx (с этой версии) есть указатель на экземпляр класса (MainClass), в котором этот элемент и находится.
Так каких указателей нам еще не хватает, и в чем открытая Америка-то
Обойтись обычным копированием можно и сейчас - это вопрос интерфейса, а не генерации кодов. Просто, иногда и копирование необходимо, например, чтобы всего лишь изменить пару связей.
Ну непосредственно и про "править". Целью исправлений было перевод теоретических рассуждений предыдущих постов, в проверенные факты.
Перевел, для меня это теперь проверенные факты. И у меня теперь есть инструмент для изучения источников неконтролируемого расхода памяти.


4)
Так что же, все-таки, будет казаться более логичным многим
Этот вопрос очень важен, хотя бы потому, что и в следующий раз тоже есть шанс сделать чего-то не из той оперы. Хотя это и будет казаться более логичным. Многим.....
Даже если Вы предпишите лежать определению класса (а содержимое мультика является определением класса с незапамятных времен) в другом файле, или просто в отдельном месте, то как Вы по-другому сделаете рекурсивную ссылку Расскажите - и я не буду "править", а буду поступать именно так, по-другому.
Постановка вопроса, что рекурсивная ссылка - это буржуазная лженаука, НЕ УБЕЖДАЕТ. А других гарантированных методов рекурсии в HiAsm, я пока не слышал.
Но можно сказать и так:

Тогда, конечно, обсуждать нечего.

5)
Схему привести не могу по той причине, что сегодня схема в среде, и содержимое буфера обмена (как и сохраненного файла) это не одно и тоже.
Схема рекурсивного варианта сортировки лежит на форуме - два внутренних мультика заменил ссылками на новый внешний мультик. А этом новом внешнем мультике раположил ссылку на самый первый внешний мультик и соединил связями.
Что "лазание" по таким вложениям приводят к катастрофе я знал заранее, поэтому не лазил без необходимости, а откомпилировал в режиме Ctrl+D. Исходил из того, что проблемы среды и проблемы генерации кодов - это разные проблемы. Далее, по вышеописанному:

Просто теперь я знаю как с этой бедой справляться: включения юнитов вложенных мультиков перенес в раздел implementation. Например так:
[code:1]unit hiMultiElementEx_4B5FDF4;
interface

uses kol,Share,Messages,hiEditMultiEx,hiMultiElementEx{,hiMultiElementEx_4B6BEE4}; //отсюда убрал,

type
TClassMultiElementEx_4B5FDF4 = class
private
EditMultiEx_4B5FED0:THIEditMultiEx;
MultiElementEx_4B69E90:THIMultiElementEx;
public
Child:THIEditMultiEx;

constructor Create;
destructor Destroy; override;
end;

TMainClass = object
function Create(Control:PControl):THiEditMultiEx;
end;

var _Create_hiMultiElementEx_4B5FDF4:TMainClass;
implementation
uses hiMultiElementEx_4B6BEE4; //а сюда вставил
.............................
[/code:1]
И так в обоих файлах. Хотя, для размыкания кольца, достаточно было в одном. И от того, что я это проверил, это перестало быть теорией.
Вот и все

Все это, безусловно, есть, но только не в SHA файле. Там каждому мультику приписывается новый EditMulti (из-за чего собственно и были созданы ссылки). Но, как вы сами говорили, зачем копировать все свойства мультика, когда нужно скопировать только указатель на определенный EditMulti.

Я именно про интерфейс и веду разговор.

Я не против рекурсии. Только к этому надо подходить осторожно.

1) Не о том подумал сначало..
2) На то он и отладочный режим, что не все там как надо. Но это конечно вопрос времени.
3-5) Ну давайте сначала. Как только появился компонент MultiElementEx тут на форуме(не вспомню сейчас кем именно) была предложена такая вот интересная идея: управлять MultiElementEx'ом из парного компонента и даже схемка была приведена:
[code:1]Add(MultiElementEx,9866221,224,-8) {
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,2254339,3,3)
{
WorkCount='doWork1','doWork2'
EventCount='onEvent1'
}
END_SDK
Add(InfoTip,10684789,98,-43)
{
Info=' Объявление класса. даем ему имя например MyClass'
Font=[MS Sans Serif,8,0,0,1]
Width=323
Height=81
}
Add(MultiElementEx,4324083,280,244)
{
link(onEvent,8459683:doWork1,[(322,250)(322,227)(256,227)])
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,14744780,3,3)
{
WorkCount='1','2'
EventCount='onEvent'
}
Add(Memory,9622648,63,154)
{
Default=String(MyClass)
@Hint='Имя класса=Имя динамически создаваемого класса'
}
END_SDK
Add(MultiElementEx,11818633,224,118)
{
link(onEvent,7010798:doMessage,[])
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,14744780,3,3)
{
WorkCount='1','2'
EventCount='onEvent'
}
Add(Memory,9622648,63,154)
{
Default=String(MyClass)
@Hint='Имя класса=Имя динамически создаваемого класса'
}
END_SDK
Add(Message,7010798,441,118)
{
}
Add(InfoTip,7235692,98,62)
{
Info='Это парный компонент ничего общего с контейнером не имеющий. Он автоматически создает экземпляр класса(его имя указывается в св-ве name) при выызове методов и уничтожает его при их отработки.'
Font=[MS Sans Serif,8,0,0,1]
Width=323
Height=102
}
Add(InfoTip,4170223,98,181)
{
Info=' А раз так то схема ниже это само собой разумеющееся св-во данного компонента без ссылок на самого себя.'
Font=[MS Sans Serif,8,0,0,1]
Width=323
Height=109
}
Add(Button,6425824,42,118)
{
Left=140
Top=195
Font=[MS Sans Serif,8,0,0,1]
link(onClick,11818633:1,[])
}
Add(Button,15097727,203,244)
{
Left=140
Top=195
Font=[MS Sans Serif,8,0,0,1]
link(onClick,8459683:doWork2,[])
}
Add(HubEx,8459683,252,237)
{
link(onEvent,4324083:1,[])
}
Add(InfoTip,11939177,98,314)
{
Info=' Ну и последнне преимущество. Объявление класса это контейнер, который можно вынести в качестве пользовательского компонента в палитру компонентов - его изменение приведет к изменению всех элементов данного класса во всех проектах.'
Font=[MS Sans Serif,8,0,0,1]
Width=323
Height=81
}
[/code:1]

наверно имя указываемое в св-ве прного элемента и есть указатель на класс, который будет использоваться. Ведь экземпляры создаются только при вызове методов, а значит это он и есть в вольной терминологии. Конечно это цифра(адрес), а всего лишь термин.

Galkov, на самом деле конечно же чем бельше среда умеет тем лучше. Сделать такое рекурсирование на самого себя действительно не сложно и если вы опишите решение указанных выше проблем, то почему бы и не добавить? ( Проблемы с кодом меня не интересуют ).

Гость,
1) Говорить о том, что сегодня лежит в SHA-файле для случая ссылок сегодня преждевременно, поскольку сегодняшнее содержание просто ошибочно.
2) Я не считаю, что вход во внутреннюю схему мультика через два промежуточных элемента зто самое рациональное решение. Да и понятие рациональности бывает разное (объем кодов и быстродействие - разные критерии). Но так сделал Автор (который, по моему пониманию, имеет право на иное, отличное от нашего, понимание рациональности), и НЕ это является препятствием для введения новых возможностей в среду. К тому же EditMulti является интерфейсным элементом и для другого типа контейнеров.
3) Именно так сегодня и делается для мультиков де-факто. Создание ссылки в схеме приводит к появлению MultiElementEx (который является интерфейсным между остальной схемой и EditMultiEx), у которого свое поле FChild, но (в отличии от копии :! поле FOnCreate указывает на уже существующий класс. А в случае копии - это был (и есть, впрочем) каждый раз новый класс.
4) Говоря про интерфейсные вещи, не следует забывать и вопросы совместимости. Поэтому, менять смысл сегодняшнего копирования - это не совсем приемлимо, ИМХО. Тем более, что копирование - не самая бесполезная операция:

Вообще-то существование двух типов мультиков - это только дань совместимости. Как и элемент GetData. Наверное, на каком-то этапе их следует поместить в раздел "раритет", а позже и удалить из среды.
Значит, логичным является существование ДВУХ (а не одной) разновидностей копирования: с созданием НОВОГО класса (с возможностью его, класса, дальнейшего редактирования), и новый экземпляр ТОГО ЖЕ класса.
Так вот. Все ЭТО в этой версии уже появилось. Обыкновенное копирование - создание нового класса, а ссылка - новый экземпляр класса-оригинала. И именно по указателям идет там работа. Но с небольшими проблемами, как интерфейсного характера, так и на уровне генерации кодов. Про преодолимость интерфейсных проблем рассуждать уверенно не могу (но не вижу принципиальных препятствий исключающих их преодоление), а на уровне генерации кодов - не принципиальные, могу сказать точно.
5) Про осторожность. Если появляется возможность делать рекурсию, то у пользователя есть возможность переполнить память при ЛЮБОЙ осторожности среды. Я выкидывал на форум 20-раз проверенный пример, однако получил ответ - НЕ РАБОТАЕТ !!!. Выясняется - бесконечная рекурсия. Ограничения, что в этом должен участвовать мультик только в динамическом исполнении, и обязательно Ex - не совсем оправданы. Достаточно одного динамического мультика в рекурсивном кольце, вызывающего методы ##add/##delete. Дополнительный интеллект, проверяющий этот факт - это конечно хорошо, но его наличие все-равно не дает гарантий безопасности. Поэтому и его отсутствие не является безусловным препятствием к внедрению фичи рекурсий.

Я скоро вообще понимать перестану о чем и с кем спор ведется
http://www.si-tech.ru/hiasm/down/hiasm_up1.rar

MultiElement действительно вещь устаревшая и ничего такого особенного не умеет(в отличие от MultiElementEx)

Dilma, у меня сейчас проблемы со связью - быстро писать не успеваю

Dilma, После этого апдейта в SHA-файле иформации вроде бы достаточно, и все логично.
[code:1]Add(MultiElementEx,2763959,140,210) {
@IsLib=True
}
BEGIN_SDK
Pos(0,0)
Add(EditMultiEx,3997859,3,3)
{
WorkCount='1'
DataCount='2'
link(1,7530434:doMessage,[(3,83)])
}
Add(Message,7530434,84,77)
{
link(Caption,3997859:2,[(97,3)])
}
END_SDK
Add(Edit,13663852,147,63)
{
Left=10
Top=110
Font=[MS Sans Serif,8,0,0,1]
Text="---"
}
Add(Button,7044785,70,112)
{
Left=70
Top=110
Font=[MS Sans Serif,8,0,0,1]
Caption="Ура"
Data=String(Ура)
link(onClick,12717030:1,[])
}
Add(Button,2719057,70,154)
{
Left=70
Top=140
Font=[MS Sans Serif,8,0,0,1]
Caption="Гм..."
Data=String(Гм....)
link(onClick,3269657:1,[])
}
Add(Edit,12501896,140,21)
{
Left=10
Top=140
Font=[MS Sans Serif,8,0,0,1]
Text="+++"
}
Add(MultiElementEx,12717030,147,112)
{
elink(2763959)
link(2,13663852:Text,[])
}
Add(MultiElementEx,3269657,140,154)
{
elink(2763959)
link(2,12501896:Text,[])
}[/code:1]
Но среда этого принимать все-равно не хочет. Сначала говорит про Acess violation.... , а потом сообщает об отсутствии 4-х точек. Видимо EditMulti ищет.......
Такое ощущение, что магического слова elink она не понимает.......

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

Кстати, если сделать ссылку на мультиэлемент, то при сохранении будет вствлен тоже мультиэлемент, но пустой, а при попытке открыть этот файл вылетает сообщение об ошибке.

Как я посмотрю с патчем ещё хуже так что качать пока не буду
ждемс следующего обновления...

Dilma, по поводу идеологии, изложенной в вышестоящем примере.

1) Первый Tip:
Место расположения определения класса не является особенно принципиальным. Для меня, по крайней мере. Меня больше интересуют возможности получения результата в проге. И какие затраты для программиста это требует.
Здесь больше играет роль, наверное, совместимость с уже имеющимся. А сегодня мы имеем то, что любая схема, в любом мультике, является определением класса.

2) Про второй Tip:
Вы могли обратить внимание, что это как раз то, что я сегодня использовал а примерах. И даже думаю, что это надо внедрить в MiltiElementEx.doWork. Например так:
[code:1]procedure THIMultiElementEx.doWork; var F:THIEditMultiEx; Cnt:integer;
begin
if FChild = nil then begin
//_debug('Please set sub sheme')
F := FOnCreate(FControl);
F.Parent := Self;
FList.Add(F);
Cnt := FList.Count-1;
_hi_OnEvent(F.Works[Index],Data);
THIEditMultiEx(FList.Items[Cnt]).MainClass.Destroy;
FList.delete(Cnt);
end else _hi_OnEvent(FChild.Works[Index],Data);
end;[/code:1]И [b]Ампер[/b] не будет напуган иностранным сообщением, и, действительно, удобно.

3) Третий Tip:
Отлично. Только это уже можно делать сейчас, и это не закрывает всех потребностей рекурсивного вызова. Хотя какие-то рекурсивные задачи это решает. Не будем далеко ходить, а попробуем использовать это в примере рекурсивной сортировки. И я пока не представляю, как там обойтись этим методом. Именно из-за верхней точки....
Наверное можно, если массив на элемент подавать через входной поток посредством DoData, а не через верхнюю точку, внутри мультика фиксировать его в Memory, и вместо рекурсивных вызовов делать вызов внешнего метода "закольцованного" на вход, помещая при этом новые массивы тоже в поток, опять же посредством DoData.
Может и получится.....
Но назвать это более понятным, у меня язык не поворачивается. А по кодам - просто больше переходов из мультика в мультик.
Ну определили мы класс. Так это еще ни о чем не говорит, оказывается, пока не устроишь внешнее кольцевание. Не думаю, что такая реализация именно этой задачи будет более понятна многим, чем ранее [url=http://si-tech.ru/hiasm/forum/viewtopic.php?p=10561#10561]приведенная[/url]. А по жизни задачки и похитрей могут встретиться.
Ну а если "колечко" более понятно - так на здоровье :!: Оно прекрасно реализуется сегодня. А доработку типа OnlyOnce я просто поддерживаю.

4) Четвертый Tip
Ну тут думаю и спорить не о чем. В другой файл, теоретически, можно вынести любую схему мультика. Смысл диспута был не в разделении на шаблон/реализация (хотя мне и кажется что особого смысла городить огород - нету), а в возможности или нет при определении этого шаблона использовать реализацию его самого.
И запрет мне кажется надуманным, чисто логически. Если мы определяем шаблоны, то для того, чтобы наделить их правами других элементов. А внутри шаблона мы можем использовать все элементы, в том числе и определенные через эти шаблоны. И тут на тебе - радость :!: Не все оказывается - себя нельзя. С чего :?: Рекурсий все равно не избежать, они могут и косвенными оказаться...

[quote="Dilma"]Сделать такое рекурсирование на самого себя действительно не сложно и если вы опишите решение указанных выше проблем, то почему бы и не добавить? ( Проблемы с кодом меня не интересуют ).[/quote]
1) Ну про коды не говорим - договорились, что на сложно.

2) Так в том то и дело, что в интерфейсной части мне представляется все нормальным и понятным. И необходимости в принципиальных изменениях как-то не усматриваю.
Если просто преодолеть явно выраженные сегодня глюки. Ну это катастрофа при гулянии по рекурсивным вложениям, и корректный прием средой уже правильного SHA-файла (о правильности файла сужу только по его логической непротиворечивости).
Сегодня дело обстоит так:
[list]а) любая схема внутри мультика - это определение класса (или ЭЛЕМЕНТА в терминологии пользователя)
б) копия мультика - это создание нового класса
в) ссылка на мультик - это создание реализации класса-оригинала
г) существуют ли у мультика конкретные реализации, и их количество - зависит от установленного свойства Mode, от предыстории вызванных методов[/list:u]
Ну и не вижу в этом ничего плохого.
3) Вот не совсем понятна мне история с копированием свойств....
Но, пока нет развернутой системы формирования свойств у мультиков, это можно и не обсуждать.
А что такое ссылка не на мультик, мне не очень понятно. Здесь есть только безусловное дублирование свойств.
Фича введения связанных копий, конечно, очень полезна. Как я представляю, было бы полезно иметь, например, одну числовую констнату, которая может появиться в Default-е счетчика, в формуле, в тексте, наконец. Иконка программы могла бы гарантировано совпадать с картинкой на форме, или с иконкой дочерней формы. Это все бесконечно полезные вещи. Могли бы быть. Если бы они не привязывались к элементу. Хочу я иметь гарантированное совпадание свойств End элемента For. Но никак не могу понять, за какие провинности меня заставляют чтобы совпадало и св-во Start. Видимо ссылки на визуальные элементы не очень применимы именно по этой причине......
Ну вот и получается, что использование фичи связанных копий ограничено тем, что они выполняются сразу пучком для всего элемента. А использование ссылок на мультики будет ограничивать пользователя тем, что нельзя поставить индивидуальные св-ва (у нашего коллеги это могла бы быть шахматная фигура).

Но это все второй вопрос, как мне представляется, хотя и с непонятным пока решением...

Пришлось разбор схемы двупроходным сделать:
http://www.si-tech.ru/hiasm/down/hiasm_up2.rar

во преки ожиданиям скорость загрузки возросла ~1.5раза. Проверено на схеме Statusplan_v0.1.sha(10638 элементов). Показаное время ~3c против ~5 на старой версии.


Кто же это запретил Сейчас невозможность делать ссылки на себя связана с невозможностью отобразить это в редакторе и об этом уже шла речь:


3)


История очень простая:
[code:1]Add(PictureTip,4186588,203,63) {
Picture=[ZIP760B000078DA73F22DE36600033320D600620120B6016246
0609B0B803541E1944CF5E45129A78F9294968F2D5E724A169375E928466
DC7C4D129A73F71D4968DEBD0F24A1F90F3E9284163FFE42125AFAF41B4
968C58B9F24A155AF7E9184D6BDFD4B12DAF0FEFF281A45A368148DA211
8848AD2FD6BCFE4D125AF5F2174968D9B3EF24A1254FBE9284163EFC4412
9AFFE0034968F69DB724A199B75E9384A65E7F491222B5BDD77FE90949A8
EFC2A341850054B96C66]
Frame=1
@IsLib=True
}
Add(PictureTip,8106074,219,63)
{
elink(4186588)
}
Add(PictureTip,8766514,235,63)
{
elink(4186588)
}
Add(PictureTip,4147632,251,63)
{
elink(4186588)
}
Add(PictureTip,5087355,267,63)
{
elink(4186588)
}
Add(Shape,6881217,91,28)
{
Width=456
Height=10
Font=[MS Sans Serif,8,0,0,1]
Color=12632256
@IsLib=True
}
Add(Shape,12002792,91,147)
{
elink(6881217)
}
Add(Shape,2824624,91,280)
{
elink(6881217)
}
Add(InfoTip,8844714,91,42)
{
Info='********************************************************'
Font=[MS Sans Serif,8,0,0,1]
Width=456
Height=102
}
Add(InfoTip,5836529,91,161)
{
Info='@@@@@@@@@@@@@@@@@@@@@@@@@@'
Font=[MS Sans Serif,8,0,0,1]
VAlign=1
Width=456
Height=116
}
Add(PictureTip,9452268,283,63)
{
elink(4186588)
}
Add(PictureTip,3813041,299,63)
{
elink(4186588)
}
Add(PictureTip,1210977,315,63)
{
elink(4186588)
}
Add(PictureTip,1700085,331,63)
{
elink(4186588)
}
Add(PictureTip,6798987,347,63)
{
elink(4186588)
}
Add(PictureTip,10748411,363,63)
{
elink(4186588)
}
Add(PictureTip,4563139,379,63)
{
elink(4186588)
}
Add(PictureTip,5475983,395,63)
{
elink(4186588)
}
Add(PictureTip,7857915,411,63)
{
elink(4186588)
}
Add(InfoTip,11465308,224,77)
{
Info='HiAsm'
Font=[Times New Roman,18,1,8388608,204]
VAlign=1
Width=183
}
[/code:1]

вы примере 16 картинок и 3 полоски, которые должны быть все время одинаковыми(кроме того сколько бы весил файл быдь он сохранен в старой версии?). По поводу GlobalVars я тоже уже говорил. Сюда укладывается любой компонент, используемый в данном проекте в качестве ф-ции с фиксированными настройками. Вот программа расчета размеров столбцов(к примеру конечно):
[code:1]Add(Button,10206548,77,49) {
Left=80
Top=60
Font=[MS Sans Serif,8,0,0,1]
link(onClick,10843669:doOperation,[])
}
Add(Label,898632,252,49)
{
Left=155
Top=60
Font=[MS Sans Serif,8,0,0,1]
}
Add(Button,4864526,77,91)
{
Left=80
Top=90
Font=[MS Sans Serif,8,0,0,1]
link(onClick,4542442:doOperation,[])
}
Add(Label,12853249,252,91)
{
Left=155
Top=90
Font=[MS Sans Serif,8,0,0,1]
}
Add(Button,1346851,77,133)
{
Left=80
Top=120
Font=[MS Sans Serif,8,0,0,1]
link(onClick,6991770:doOperation,[])
}
Add(Label,14740415,252,133)
{
Left=155
Top=120
Font=[MS Sans Serif,8,0,0,1]
}
Add(Button,1033615,77,175)
{
Left=80
Top=150
Font=[MS Sans Serif,8,0,0,1]
link(onClick,2111131:doOperation,[])
}
Add(Label,7608949,252,175)
{
Left=155
Top=150
Font=[MS Sans Serif,8,0,0,1]
}
Add(Math,10843669,147,49)
{
link(onResult,1930375:doStrCat,[])
}
Add(Math,4542442,147,91)
{
link(onResult,4538519:doStrCat,[])
}
Add(Math,6991770,147,133)
{
link(onResult,4980011:doStrCat,[])
}
Add(Math,2111131,147,175)
{
link(onResult,15695202:doStrCat,[])
}
Add(StrCat,1930375,196,49)
{
Str2="px"
@IsLib=True
link(onStrCat,898632:doText,[])
}
Add(StrCat,4538519,196,91)
{
elink(1930375)
link(onStrCat,12853249:doText,[])
}
Add(StrCat,4980011,196,133)
{
elink(1930375)
link(onStrCat,14740415:doText,[])
}
Add(StrCat,15695202,196,175)
{
elink(1930375)
link(onStrCat,7608949:doText,[])
}
[/code:1]
тут StrCat это фиксированная ф-ция отображения чисел на экране, которая по логике программы абсолютна одинакова для любого расчитываемого мною числа, а потому захочу я сменить "px" на "точки" то не буду лазить по всему проекту в поиске этих элементов. И т.д. и т.п.

Картина та же самая - при сохранении проекта вместо ссылок на компоненты в sha-файлы вставляются сами компоненты со свойствами по умолчанию, а вместо ссылок на мультик - пустые мультики.

Но копировать и вставлять схемы со ссылками теперь удается без проблем - уже лучше, чем было

Поправочка - замена ссылок компонентами происходит не при сохранении, а при открытии файла.