MultiElementEx

Форумы ПрочееMultiElementEx ← Ctrl1 23Ctrl →

Этот топик читают: Гость

Ответов: 9906

Рейтинг: 351

#31: 2006-10-09 15:32:43 ЛС | профиль | цитата

Пусть стоит задача: методы Delete должны быть ДУРАКОУСТОЙЧИВЫ

Ну скажем такой набросок:
для EditMultiEx.pas

.....
 PListEH = ^TListEH;
 TListEH = record
   Hnd:THIEditMultiEx;
   Prv:PListEH;
 end;

implementation

uses hiMultiElementEx;

procedure THIEditMultiEx.onEvent;
var X:TListEH;
begin
  X.Hnd := Self;
  X.Prv := THIMultiElementEx(FParent).EvHandle;
  THIMultiElementEx(FParent).EvHandle := @X;
  _hi_onEvent(THIMultiElementEx(FParent).Events[Index],Data);
  THIMultiElementEx(FParent).EvHandle := X.Prv;
end;
.....

и для MultiElementEx.pas

.....
procedure THIMultiElementEx.HDelete(var Data:TData; Index:word);
var F:THIEditMultiEx;
    G:PListEH;
begin
   F := THIEditMultiEx(ToInteger(Data));
   if FList.IndexOf(f) = -1 then exit;
   G := EvHandle;
   while assigned(G) do begin
     if F=G.Hnd then begin
       _debug('Ты чё, сдурел ?!');
       exit;
      end;
     G := G.Prv;
    end;
   _hi_OnEvent(F.Works[Index],Data);
   if FChild = F then FChild := nil;
   F.MainClass.Destroy;
   FList.Remove(F);
end;
.....

карма: 9

Ответов: 2125

Рейтинг: 159

#32: 2006-10-09 18:25:43 ЛС | профиль | цитата

Galkov писал(а):

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

Это для нас с тобой "всё ещё кем-то вызван", а пользователь вполне может считать, что раз поток вышел из мультика с правой стороны, то данный мультик уже не занят и его вполне можно удалить.

З.Ы. Как там было про оптимизацию хвостовой рекурсии?

карма: 1

Ответов: 9906

Рейтинг: 351

#33: 2006-10-21 02:52:13 ЛС | профиль | цитата

хвостовой рекурсии - звучит неплохо

Вот мне и представляется, что "красивый" <Отладочный режим> должен демонстрировать пользователю, что функционирование схемы в HiAsm - это НЕ передвижение фишки по карте.

А, скорее - "развивающееся" дерево....
И этот общеобразовательный фактор мне представляется очень важным.
Настолько, что не жалел бы здоровья на:

ПодЦвечивать все активное дерево целиком, а не только последний линк
Анимацию - постепенную подЦветку линка при входе в линк, и аналогичное снятие подЦветки при выходе. Одинаково - и для вертикальных, и для горизонтальных линков.
При входе в мультик, раскрывать его в новом окне (возможно опционально). Естественно, с возможностью "гулять" по окнам, рассматривая с пристрастием - где чего подЦвечено
Позволить окнам "вытаскиваться" - хотя бы для того, чтобы можно было одновременно видеть подЦветку на нескольких уровнях
А можно еще и подсчитывать (и показывать) уровень _hi_onEvent-вложенности. И предупреждения давать при попытках "кольцевания", когда "хвостовая рекурсия" не ликвидирована - на этапе исполнения посчитать все можно...
А если, при просмотре подЦветки, курсор попадает на подЦвеченный линк, то хинтом (всплывающим, или в окне справка - технические детали) можно и напомнить - чего там в последний раз было

Ну, это так - на вскидку....
Нам то это не очень надо. А вот понимание происходящего "средним" юзером - дорогого стоит.

[size=-2]------ Добавлено в 02:52
Dilma, а чего ты про это ничего не говоришь

А вот подать на ##Add данные для внешних св-в в виде MT-списка - было бы дело ..........
И реализовать это CodeGen-ом в конструкторе схемы...

В одном загвоздка - СРЕДА

не сообщает в CodeGen о том, какое св-во внешнее, а какое нет
Надо бы придумать такой интерфейсный метод с префиксом sdk ...

карма: 9

Разработчик

Ответов: 26151

Рейтинг: 2127

#34: 2006-10-21 09:53:36 ЛС | профиль | цитата

Galkov, очень неплохо бы иметь еще и определение индекса на Debuger'e при подключении внутри мультика, а то при активации насыпет на экране кучу, и разбирайся к какому ##select'y оно относится.

карма: 22

Администрация

Ответов: 15295

Рейтинг: 1519

#35: 2006-10-26 20:56:54 ЛС | профиль | цитата

Видимо нужно добавить еще один метод bool isInternalProperty() {}

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#36: 2006-10-26 21:19:02 ЛС | профиль | цитата

А чего только is

Не плохо бы char* ExternalName() {} ....
И возможность объединить несколько внутренних св-в одним внешним именем могла бы оказаться не лишней ....

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#37: 2006-10-26 21:38:10 ЛС | профиль | цитата

Как это?

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#38: 2006-10-26 22:51:38 ЛС | профиль | цитата

Ну, скажем, в таком случае

Add(MultiElementEx,9647642,217,196)
{
 @IsLib=True
}
BEGIN_SDK
  Add(EditMultiEx,5921674,3,3)
  {
   WorkCount=#30:doAnything=Сделать чего нибудь|
  }
  Add(Counter,578814,98,42)
  {
   MakeExt(Max,Максимальное значение,MAX)
  }
  Add(For,2490835,98,98)
  {
   End=100
   MakeExt(End,Максимальное значение,MAX)
  }
END_SDK
Add(MultiElementEx,1862395,217,112)
{
 elink(9647642)
}

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

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

Следующим шагом (после "разлинковки" св-в) сближения элемента с мультиком - выкинуть вообще св-во Mode. Сделать просто два разных мультика отдельно: статический и динамический. Тогда в панели св-в будут только св-ва элемента.

И с точки зрения CodeGen все было бы "по честному": для мультика читается список св-в, заряжает значениями этих св-в MT_Data, которые передает вторым параметром в конструктор схемы (первый - Control). Это для статического мультика.
А для динамического - эту "зарядку" делает программер и отправляет в потоке на ##add

[size=-2]------ Добавлено в 22:30
Да, возможность LIB-модуля была бы тоже не лишней.
code_493
Не очень понятно, правда, как сделать, чтобы простые копии из библиотеки в схему не попадали...
Или, чтобы при попадании, было сразу видно, что ты сделал чего-то не то...

BTW: А вместо INLINE библиотеки можно ведь и link-контейнер использовать...

карма: 9

файлы: 1 code_493.txt [985B] [449]

Форумы ПрочееMultiElementEx ← Ctrl1 23Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)