BD> Возможно ли поменять Driver файла во время выполнения?
BD> FileXXX{PROP:Driver} =
BD> Почему то не помогает.

Нет, легально не получится. Свойство PROP:Driver ТОЛЬКО возвращает наименование драйвера для данного файла. Но не меняет его.

В принципе, есть два варианта:

1. использовать библиотеки третьих разработчиков, например, что-то типа MetaDriver.
   Там это сделано через подстановку в качестве драйвера своей «пустышки». А уже в пустышке» они перенаправляют запрос нужному драйверу.
2. делать это самому, просто меняя в заголовке файла адрес точки входа в нужный драйвер.

Второй вариант, имхо, более предпочтителен. Хотя-бы потому, что использует ТОЛЬКО ЛЕГАЛЬНЫЕ средства самого Клариона.
Нет необходимости в подключении самописных драйверов, которые, к тому-же, необходимо корректировать в зависимости от версии Клриона. Читать далее →

ОАР>> А вот {PROP:Name} прекрасно возвращает текущее имя файла.

VS> Но вот у {PROP:Name} есть другая проблема (по крайней мере была на C5
VS> и ранних релизах C55) — инициализировать {PROP:Name} нужно перед
VS> каждой «глобальной» операцией типа OPEN/CREATE/BUILD etc
VS> Так что пользовать {PROP:Name} нужно тоже с осторожностью.

Да тут надо просто понимать, как этот механизм работает!
А все довольно просто. Как всегда — дело в трейдовости файлов и в потоках, в которых эти файлы работают. Читать далее →

AP> 3. Когда уничтожаешь созданную через NEW() очередь — обязательно ли перед
AP> DISPOSE делать FREE()? ANY полей — нет, только обычные STRING/LONG итд

Для очередей оператор Dispose() транслируется компилятором в вызов отдельной функции ядра, предназначенной именно для уничтожения очередей. Так как очередь «изнутри» представляет собой обычный обьект (класс), то для его уничтожения вызывается деструктор этого обьекта. А в числе первых операторов этого деструктора стоит вызов «ядренного» эквивалента оператора FREE(). Разница между этими функциями следующая:

Обычный оператор FREE()

вызывает метод-деструктор для объекта — списка записей очереди.
вызывает метод-деструктор для объектов — ключей очереди.
вызывает метод-конструктор для объекта — списка записей очереди.

метод FREE деструктора очереди

выполняет первые два шага обычного оператора FREE().
вызывает методы-деструкторы для вспомогательных объектов очереди.
освобождает ВСЕ занятые при инициализации области памяти.

Так что, как видно, вызов оператора FREE() перед DISPOSE()
НЕ является необходимым. Спокойно можно обойтись и без него.

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-таблицах ВСЕГДА хранится в сжатом виде! И, следственно, по сетке передается именно в сжатом виде. Читать далее →