AA> А как бы почитать сии дебаты, учитывая, что я позжее подписался на
AA> КлаЛист? 🙂

ВНИМАНИЕ!!!

Все нижесказанное справедливо ТОЛЬКО для C55!
В версии C50 есть некоторые, незначительные, отличия.
Которые, впрочем, запросто могут привести к GPF!
Правда, надо заметить, что эти отличия касаются ТОЛЬКО правильного определения адреса UFO-обьекта, который в C55 определяетя просто через Address(Any).
В C50 необходимо немного «извратиться».
Если кому необходимо именно для С50 — пишите, подскажу.
Что-же касается описания INTERFACE и всех остальных структур, то они идентичны для обеих версий.
Как это работает в C56 — не знаю, нет ее у меня. Читать далее →

Здесь уже шел разговор о новых функциях ядра C55.

Вот еще несколько полезных:

  MAP
    MODULE('Clarion RTL')
      GROUP::PutINI(*GROUP _Group,STRING _Section,STRING _INIFileName),NAME('Cla$PUTINIGROUP'),DLL(dll_mode)
      GROUP::GetINI(*GROUP _Group,STRING _Section,STRING _INIFileName),NAME('Cla$GETINIGROUP'),DLL(dll_mode)

      sLen(*STRING _Str),LONG,NAME('Cla$FastClip'),DLL(dll_mode)
      sLen(LONG _Size,LONG _Addr),LONG,NAME('Cla$FastClip'),DLL(dll_mode)
    END
  END

sLen — быстрый вариант определения длины строки STRING. Данная функция быстрее LEN(CLIP(STRING)) ~2 раза. Во-первых, за счет того, что не использует строковый стек, и Во-вторых, для строк длиннее 16 байт использует оригинальный алгоритм с наложением 4-байтной маски из пробелов.

К сожалению, не допускает форму использования (STRING _Str).

Процедуры GROUP::xxx позволяют сохранять/восстанавливать сразу всю группу. Группа автоматически «разворачивается» по полям:

TstGrp  GROUP,PRE(TST)
Name      STRING(60)
Code      LONG
Price     DECIMAL(12,2)
        END

  TST:Name = 'Зубная паста'
  TST:Code = 12345
  TST:Price = 35.00
  GROUP::PutINI(TstGrp,'TstGrp',GLO:stNameINIFile)

запишет в файл GLO:stNameINIFile строки:

[TstGrp]
TST:Name=Зубная паста
TST:Code=12345
TST:Price=35

SK> Возник вопрос, а возможно ли копировать значения
SK> из очереди в массив быстрее чем с использование
SK> стандартного оператора GET(Que,Ind)

Вообще-то, не так давно в этом списке уже был подобный вопрос. И ответ на него был вполне определенный — НЕТ. Читать далее →

A> c55, clarion
A> Как форма Update — Change узнает, какую запись ей обрабатывать?
A> Как заставить эту форму обрабатывать конкретную нужную мне запись не
A> используя броуз?

Форма «Update» обрабатывает ТЕКУЩУЮ запись Главного файла формы.
Т.е., если в файловой схеме формы, в качестве Primary файла задан, например, файл «Members», то необходимо:

1. Выполнить чтение нужной записи:

   - GET(Members,...)
   - SET(Members) - NEXT(Members)/PREVIOUS(Members)

2. Выставить глобальный флаг операции:

   GlobalRequest=ChangeRecord

3. Вызвать процедуру формы.

Как именно закончилась работа формы (Ok/Cancel) обычно можно через переменную GlobalResponce. «Обычно» — если используешь стандартную форму. В других случаях — зависит от логики разработчика программы.

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

Но, обсуждая все эти вопросы, мы почему-то всегда упускали из виду одну особенность TPS-драйвера, которая ОЧЕНЬ существенно влияет именно на сетевой трафик и, как следствие, на скорость выборки из TPS-таблиц! А именно — информация в TPS-таблицах ВСЕГДА хранится в сжатом виде! И, следственно, по сетке передается именно в сжатом виде. Читать далее →

PS>> Имеется некий класс…
PS>> Если прописать одну из его очередей в качестве источника для List,
PS>> т.е. в поле From написать AnyClass.AnyQueue — компилятор,
PS>> естественно, глотает, но в runtime при открытии окна имеем:
PS>> Internal error 01: WSLDIAL
PS>> Do you want to GPF?

VS> Это просто RTL так реагирает на нарушение принципа инкапсуляции данных
VS> Мол нефиг — мемберы не должны быть публичными…
VS> И может быть в этом и заключена вся серомяжная правда? 😉

PS>> Естественно, клас проинициализирован на момент открытия
PS>> окна и очереди созданы, но увы…
PS>> А так хочется прописать напрямую… AnyClass.AnyQueue
PS>> Кто-нибудь решал эту проблему? Решил?

VS> См. выше… Понятно, что если компилер допускает использование
VS> нерекомендуемых конструкций, от их можно использовать. Но нужно ли?

Не, Вадим, ты немного неправ. Можно. И вполне на законных основаниях. Только такую очередь надо «пристегивать» к листу НЕ на этапе дизайна, А ПОСЛЕ ОТКРЫТИЯ ОКНА!
Т.е., в данном случае, в дизайнере необходимо поле FROM оставить пустым. А во вставке «После открытия окна» надо написать: Читать далее →

OAR>> А что здесь непонятно?!
OAR>> QueRef обьявлен как УКАЗАТЕЛЬ НА ОЧЕРЕДЬ.
OAR>> При передаче его как ANY компилятор предполагает, что
OAR>> в процедуру передается БУФЕР ЗАПИСИ ОЧЕРЕДИ на которую
OAR>> указывает QueRef.
OAR>> И, соответственно, его действия следующие:
OAR>> — по указателю QueRef читает заголовок очереди, на которую
OAR>> ссылается QueRef
OAR>> — из заголовка выбирает указатель на буфер записи этой
OAR>> очереди
OAR>> — по выбраному указателю создает UFO-обьект типа GROUP
OAR>> — передает его в процедуру

AA> …
AA> QueRef &= NULL
AA> MyProc(QueInst, QueRef)
AA> …

AA> каков будет результат? QueRef ведь ИНИЦИАЛИЗИРОВАН???

OAR>> Как видно, уже на первом шаге произойдет GPF, т.к. перед
OAR>> вызовом процедуры QueRef НЕ ИНИЦИАЛИЗИРОВАН, т.е.,
OAR>> грубо говоря, QueRef &= NULL!!!

AA> ну ежели компилятору самому в облом инициализировать указатели
AA> каким-либо значением (пусть даже NULL), то уж как-то он (runtime)
AA> должен отслеживать валидность указателей…

Я, очевидно, неверно обьяснил.
Под ИНИЦИАЛИЗАЦИЕЙ понимается присвоение указателю значения ОТЛИЧНОГО от нуля, т.е. от NULL.
Я же написал, что согласно принятой схеме превращения указателя на очередь в ANY-обьект, сначала производится чтение заголовка очереди на которую ссылается QueRef. А так как QueRef &= NULL, то, соответственно, получим чтение из ячейки памяти с НУЛЕВЫМ АДРЕСОМ, что, естественно, приведет к GPF! Читать далее →

AA> Нужно ОЧЕНЬ!
AA> ! Вот только, не слишком-ли бедный получится регэксп?
AA> ! Учитывая возможности MATCH от Клариона и возможности
AA> ! стандартного регэкспа?

AA> Это СТАНДАРТНЫЙ регэксп, именно его и хочется.
AA> Если тебя не затруднит, подскажи хотя бы, где копать.

Если уж так срочно, и умеешь нормально ориентироваться в асме, и знаешь хорошо ядро Клары, то загляни в код функции Cla$REGULAR. Вот ее надо переписать на Кларионе. Ничего сложного нет. Тем более, что ВСЮ работу по поиску выполняет экспортируемая функция _7RegExpr__find@… А тебе прийдется только написать код для инициализации и завершения. И взять результат из временного буфера, который этой функции и подсунешь. Читать далее →

DmVB> В том-то и прикол, что введённые тобой значения прекрасно сохраняются!
DmVB> Т.е. было

DmVB> NewControl#{prop:use}—>88
DmVB> NewControl#{prop:value}—>88

DmVB> ввели ручками 89, стало

DmVB> NewControl#{prop:use}—>89
DmVB> NewControl#{prop:value}—>89

DmVB> Чудо!

Никакого чуда. Если у контрола нет своей физической переменной, то ядро привязывает к такому контролу неявно созданный UFO-обьект типа STRING. По умолчанию длина = 20. Но ее легко можно изменить с помощью {PROP:Text} = ‘@S???’.
Т.е., другими словами, с помощью свойства {PROP:Text} в любой момент времени выполнения можно создавать UFO-обьект ЛЮБОГО типа с ЛЮБЫМИ параметрами. Старый UFO-обьект, естественно, уничтожается.

Такие «фокусы» с изменением типа и параметров ENTRY-поля доступны, естественно, ТОЛЬКО для полей, у которых нет явно заданной физической переменной.

YF> Здравствуйте, Олег.
YF> Вы писали 4 декабря 2002 г., 3:25:23:

ОАР>> Здравствуйте!
ОАР>>> А после этого опять пробежать по очереди и сравнить оригинальные
ОАР>>> строки и значения из ASTRING.
ОАР>>> Если получим где-то несовпадения, то значит были сгенерены
ОАР>>> несколько одинаковых Hash-ключей.

YF> Любой порядочный алгоритм хеширования должен иметь средства
YF> разрешения коллизий (Д.Кнут, Искусство программирования для

Учитывая, что в моих тестах повторений не было, то SV так-же читают его книги:)

YF> ЭВМ, т.1). Я не думаю, что в SV об этом не знают. Кстати, как это
YF> соотносится с их заявлениями об использовании ATOM-фукнций WinAPI?

Явно никак. По крайней мере, в блоке работы с ASTRING-ами. Хотя, конечно, реализация ASTRING от SV сильно напоминает виндусовые Атомы.

У меня вообще давно уже сложилось впечатление, что SV никак еще не отойдет от практики разработки языка времен Виндов3.11 Когда в WinAPI многого не хватало и TopSpeed недостающее делал сам в ядре Клары. Может просто они таким образом пытаются застраховаться от возможных нестыковок и несовместимостей между API различных версий Винды? Читать далее →