Clarion 6.1

Кларионовские новости
Ответить
Гость

Сообщение Гость »

Здравствуйте!
Случайно заглянул в новости SV.

Clarion 6.1 is the first update to the gold release, and when available for
download will be free to all registered users. The instructions for download of
the 6.1 install will be posted on the website during the week of May 4th.

The Help system has received a tremendous amount of attention, thanks to all of
you who helped in that effort. To download the latest core Help file (size
4.5MB) - find it here:
http://www.softvelocity.com/clarion/hlp/c61help.zip.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

Здравствуйте, господа...

Страничка http://www.softvelocity.com/clarion/c61.htm
The patch for Clarion 6.1 is currently available as an Early Access build. This release is available for 3rd party Tool vendors (and to any users who just can't wait). Our intent is to give the tool vendors some time to rebuild their distributable binary files in preparation for the general release of 6.1, and to take the opportunity receive some immediate feedback on 6.1. The general release will be posted later this week (the week of May 10, 04).
To download the Early Access build of Clarion 6.1 click the appropriate link:
Clarion 6.1 Enterpise Edition - Early Access http://www.softvelocity.com/dl/c61ea/Cl ... atch61.zip
Clarion 6.1 Professional Edition - Early Access http://www.softvelocity.com/dl/c61ea/Cl ... atch61.zip
---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439
Написал: ClaList(2)
Гость

Сообщение Гость »

Поставил и посмотрел. Сразу же глянул место, на чем пришлось отложить 6.0.
Оно там же :(
Или быть может я что-то не так делаю?
Задача - создать тулбокс, имеющий два положения (прижать влево и вправо).
Открываемые окна в максимизированном состоянии должны подстраиваться под свободное место на экране. Все это решается в 5.5 путем включения флажка MDI-child для тулбокса и запуска его в том-же потоке, что и фрейм. Если делать то же самое в 6.1, то программа виснет намертво. Если запускать в отдельном потоке, то не работают указанные выше фичи.

Почему-то так и не включили сортировку процедур по алфавиту в окне заселения. Сделали поиск (!), но если, скажем, первой стоит процедура Prim, а где-то далее по списку Pri, то и не найдешь, пока вручную не сместишься по списку ниже первой. Это мелочь, но демонстрирует.
В репортере попрежнему нет выделения группы контролов в области и перемещения по заданной координате, хотя и в доке написано, и в RW это работает.
Это то, что увидел за несколько минут после установки.

Кстати, у буржуев народ пишет про баги.
Спокойно начинаем ждать 6.2 :-)


С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Если запускать в отдельном потоке, то не работают указанные выше фичи.
Вообще-то такая фишка по жизни работала...
Тулбокс запускается в другом потоке...
Проблема в том, что параметры, указанные в Window Properties
(Dock,Docked) не работают - их нужно вручную прописать в коде после
открытия окна

OPEN(window)
window{PROP: Dock} = DOCK:Left + DOCK:Right
window{PROP: Docked} = DOCK:Left

И все работает... по крайней мере у меня :)

Алексей,
начальник отдела ПТО
ООО "ОРК"
mail: alex@jrcn.donetsk.ua, icq: 62605472
www: http://www.nikasoft.co.uk
http://www.clarionline.h1.ru (FAQ-онлайн)
origin: ... он зачитывал диски до дыр

(Добавление)

Спасибо за ссылку!
Думаю, что модератор не сочтет твое письмо за нарушение правил данного списка?

Но! Очевидно велосипедисты уж очень спешили с данным патчем - в их "забугорной" конференции все прямо-таки "задергали" "когда, когда?!?!".
Как результат - сразу-же мелкие "баги", которые, тем не менее ставят под вопрос "чистоту" остального кода.

К примеру - автоматом не инициализируется буфер файла!
Конечно, ничего страшного - правила хорошего тона требуют явно производить очистку переменных и структур перед их использованием - но все-же, "осадочек" некоторый есть!
Группа и буфер очереди, как и прежде, инициализируются автоматом.
Правда, как-то прикольно они их инициализируют!
Если раньше для групп просто вызвался CLEAR, то теперь они инициализируют ОТДЕЛЬНО строковые поля группы и все вложенные подгруппы! Другие поля не трогают.
Т.е. если в программе обьявлено много структур с внутренними группами и строками, то заметно увеличивается обьем кода.
Время инициализации, думаю, не должно увеличится - здесь имеем просто линейную "развертку" цикла, который крутится по всем полям в операторе CLEAR.

Кстати, они довольно сильно "перепахали" весь блок RTL по работе с файлами. Да и сами файловые структуры претерпели некоторых изменений. Это следует иметь в виду тем, использует информацию из заголовка структуры FILE.
Связано это с тем, что в RTL введен блок по динамической работе с файловыми структурами. Соответственно, модифицированы и файловые драйверы, что-бы обрабатывать новые команды.

Увы! Ошибка инициализации модулей, о которой я недавно писал, в данной версии не исправлена - тестовый пример, который я высылал по этой теме, вполне "удачно валится"!

И еще - тем, кто использует DynaLib - в С61 версия, которая выложена на сайте, работать не будет с файловыми структурами. Все прочие классы данной версии должны нормально работать и в C61. Так-же нормально должна работать в C61 и либа ExtEval.
Ну и, естественно, dExcel.

Кстати, на днях выложу на сайт новую версию dExcel - добавлена поддержка формул. Причем - практически без "обрезаний", т.е. нормально будет воспринимать любую формулу в Excel-синтаксисе.
С графикой пока заминка.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru

Написал: ClaList(2)
Гость

Сообщение Гость »

Спасибо за ссылку!
Думаю, что модератор не сочтет твое письмо за нарушение правил данного списка?
Дык эта ссылка взята с офсайта SV... :)


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

Конструктор, IMHO, должен проинициализировать только внутренние объекты не ссылаясь на глобальные. Это - капсуляция данных в объекте. Если последовательность создания важна (как в данном случае), то можно использовать создающий [глобальный] объект, который рассадит созданные в нужном порядке объекты на ссылочные [глобальные] переменные.

Алексей Пуховский
3M Medica
Написал: ClaList(2)
Гость

Сообщение Гость »

Увы! Ошибка инициализации модулей, о которой я недавно писал, в данной версии не исправлена - тестовый пример, который я высылал по этой теме, вполне "удачно валится"!
А на http://cwmantis.glacierdigital.com не писал? Там вроде ребята ходят из службы поддержки велосипедистов, может и обратят внимание...
Гость

Сообщение Гость »

2Алексей Пуховский
Жаль, что ты не читал моих предыдущих писем по данной теме!
Видишь-ли, я считаю ошибкой, когда компилятор не в состоянии определить последовательность инициализации модулей даже в простейших ситуациях!

Во-вторых, если следовать твоему совету, то невозможно будет обьявлять дочерние классы статически, а только создавать их явно через NEW. Только в этом случае можно быть уверенным, что класс-менеджер проинициализируется ПЕРВЫМ, ДО вызова конструкторов классов, которые он должен регистрировать.
И, опять-же, менеджер нельзя будет делать трейдовым.

Не кажеться-ли тебе, что слишком много ограничений для простейшей ситуации!?

Но даже и не в этом дело!
Первые мои письма по данной теме описывали ошибки, связанные с неверной инициализацией ВНУТРЕННИХ обьектов Клариона!
У меня есть реальный большой проект, который я до сих пор не могу перевести на C60. И проблема именно в том, что готовый EXE-модуль "падает" сразу при запуске. Как выяснил, причина в том, что конструктор одного из файловых драйверов запускается раньше, чем конструктор менеджера памяти RTL!
А в этом конструкторе производится инициализация механизма синхронизации доступа. И именно неинициализированный по правилам Винды блок синхронизации и вызвает GPF на уровне WinAPI при попытке выделить память для файлового драйвера!
И, опять-же, блок синхронизации здесь выступает просто в роли индикатора этой ошибки - не было-бы его и не было-бы GPF, а приложение сразу-же работало-бы неверно - пойди потом разберись в чем причина!

В первых версиях C60, до того, как они внесли изменения в код компилятор, ответственный за построение списка инициализации, все это хозяйство работало правильно!

И в упомянутом выше проекте НЕТ глобальных классов, общающихся друг с другом на уровне конструкторов.
Просто компилятор по какой-то своей "прихоти" поставил вызов конструктора файлового драйвера ДО вызова конструкторов обьектов RTL!

=============================
С уважением, Олег А. Руденко

(Добавление)

Как валилось приложение при закрытии так и валится

--
С уважением,
Талгат mailto:talgat@omsknet.ru
(г.Омск)
И все работает... по крайней мере у меня :)
Сорри, это у меня кривые :D
Надо запускать в отдельном потоке, а у тулбокса признак MDI-child отключить.
Так и в 5.5 сделано, а тут заклинило. Все в 6.1 работает, в том числе и параметры в Window Properties (впрочем, как и в 5.5H).

С уважением,
Вячеслав Черников
Написал: ClaList(2)
Гость

Сообщение Гость »

Во-вторых, если следовать твоему совету, то невозможно будет обьявлять дочерние классы статически, а только создавать их явно через NEW.
А какая связь с дочерними классами? Если класс глобальный, так он глобальный.
И, опять-же, менеджер нельзя будет делать трейдовым.
Почему нет, если переменные, которые он инициализирует будут тоже
трейдовыми.
Я делаю класс

Код: Выделить всё

GLO     CLASS,THREAD
cs_MyClassReg     &CriticalSection
MyClass         &ClassA
Construct               PROCEDURE()! SELF.MyClass&=;SELF.cs_MyClassReg&=
        END
...
А в программе пользую GLO.MyClass. Все получается абсолютно легально.
Или же все таки:

Код: Выделить всё

MyClass         &ClassA,THREAD
GLO     CLASS,THREAD
Construct               PROCEDURE() ! MyClass &=;
        END
Опять же работает без проблем.
Как выяснил, причина в том, что конструктор одного из файловых драйверов запускается раньше, чем конструктор менеджера памяти RTL!
Это как это? А какой драйвер?
То есть, может быть ситуация, что у нас есть некоторый описанный файл, просто наличие которого рушит систему?

Кстати, такой код - тоже работает:

Код: Выделить всё

cs_MyClassReg        &CriticalSection
MyClass.Construct    PROCEDURE
  CODE
  If cs_MyClassReg &= NULL
     cs_MyClassReg  &= NEW(CriticalSection)
  End
  cs_MyClassReg.Wait()
Только тогда непонятно, кто будет уничтожать класс.

Алексей Пуховский
Написал: ClaList(2)
Гость

Сообщение Гость »

А какая связь с дочерними классами? Если класс глобальный, так он глобальный.
Я просто неудачно выразился. Дочерний - в смысле он должен регистрироваться в классе-менеджере. Т.е. что-то типа "подчиненного" класса?
А в программе пользую GLO.MyClass. Все получается абсолютно легально.
К сожалению, ты неверно понимаешь работу блока синхронизации доступа! Это, кстати, распространенная ошибка, которая даже иногда встречается в доке от SV.
Как работает ВинAPI-сиcтема синхронизации доступа через критические секции:
- есть группа CriticalSection
- перед использованием инициализируем ее через ВинAPI-процедуру InitializeCriticalSection.
- перед работой с глобальной переменной, которую могут изменять другие трейды (заметь - трейды, а не процессы!!!) блокируем эту критическую секцию через EnterCriticalSection.
- после работы освобождаем эту секцию через LeaveCriticalSection.

Обращаю внимание, что речь выше идет о секции, ОБЩЕЙ для ВСЕХ потоков (трейдов)!!! Т.е., что-бы синхронизация через критическую секцию работала правильна эта критическая секция должна быть ОДНА И ТАЖЕ для ВСЕХ трейдой!

В твоем-же случае получаем для каждого трейда свою критическую секцию, которая НИКАК не будет влиять на другие трейды! И, соответственно МЕЖТРЕЙДОВАЯ синхронизация работать не будет!
Именно поэтому ВООБЩЕ не имеет смысла делать критические секции трейдовыми - они ВСЕГДА должны быть ГЛОБАЛЬНЫМИ НЕТРЕЙДОВЫМИ обьектами!!!
Это как это? А какой драйвер?
В моем случае это - драйвер 'BASIC'.
То есть, может быть ситуация, что у нас есть некоторый описанный файл, просто наличие которого рушит систему?
Именно это и имеет место в случае описанной проги!
Только тогда непонятно, кто будет уничтожать класс.
Хм... Жаль, что ты не читал мои предыдущие письма по данной теме. Я в них именно и рассматривал этот случай. Самой GPF не будет, но ВСЕ РАВНО останется неверный порядок инициализации/деинициализации модулей.
Просто ты его "зрительно" никак не увидишь!
Но он-то от этого НЕ ИСЧЕЗНЕТ!!!

=============================
С уважением, Олег А. Руденко


(Добавление)

Что-то я запутался. В своё время в доке было написано

Glo:CS &ICriticalSection

Glo:Cs &= NewCriticalSection()

Glo:Cs.Wait()
...
Glo:Cs.Release()

И я этим пользуюсь. Какое отношение объектов CriticalSection и IcriticalSection?
А для объектов типа Imutex есть TryWait - подождать какое-то время, но не более указанного - весьма удобно...

---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439
Именно поэтому ВООБЩЕ не имеет смысла делать критические секции трейдовыми - они ВСЕГДА должны быть ГЛОБАЛЬНЫМИ НЕТРЕЙДОВЫМИ обьектами!!!
Просто на заметку.
1. А свойства клариных классов могут быть STATIC? Если да, то тогда эта критическая секция будет общей для всех экземпляров данного класса, и проблема решается.
2. CriticalSection - это плохо. И в MSDN это указано. Потому, что если внутри блока EnterCS-LeaveCS произойдет свал программы, то получаем дедлок, который лечится лишь рестартом всей системы.
Лучше использовать семафоры или мутексы - по крайней мере при смерти процесса, даржащего этот объект ядро его освобождает. А CS - не освобождает :-(

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: +380 572 177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836


(Добавление)
А на http://cwmantis.glacierdigital.com не писал? Там вроде ребята ходят из службы поддержки велосипедистов, может и обратят внимание...
Я написал в их (SV) официальный форум по C60.
Если там не заметили, то где гарантия, что заметят в другом месте.

Тем более, что вчера на повторное сообщение по этой ошибке ответил один товарищ. Насколько я понял - не из службы поддержки SV.

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

Вообщем, к сожалению некоторые коллеги думаю так - если есть вариант обхода "глюка", то можно не считать этот ошибкой а обычной "фичей"!
И при этом не задумываются, что есть варианты, где предложенный "обходной путь" просто не сработает!

=============================
С уважением, Олег А. Руденко

Олег, все нормально. Те кто хочет, тот увидит и сочтет это именно ошибкой, это достаточно очевидно. И большой молодец, что публикуешь на SV серваке такие вот сообщения.

Удачи!
__________________________________
Владимир Якимченко (IСQ 16 993 194)
Написал: ClaList(2)
Гость

Сообщение Гость »

Какое отношение объектов CriticalSection и IcriticalSection?
ICriticalSection - это просто интерфейс на класс RTL Клариона, реализующий работу с Виндовым обьектом CriticalSection.
А для объектов типа Imutex есть TryWait - подождать какое-то YF> время, но не более указанного - весьма удобно...
В CriticalSection тоже есть подобная процедура - TryEnterCriticalSection. Но велосипедисты просто не стали делать для нее метод - "обёртку". Правда, если необходимо, то можно использовать ее самому:

AddrCS = Address(Glo:CS) + 4 ! или INSTANCE()
if TryEnterCriticalSection(AddrCS)...

=============================
С уважением, Олег А. Руденко
ICriticalSection - это просто интерфейс на класс RTL Клариона, реализующий работу с Виндовым обьектом CriticalSection.
Немного странно. В документации и статьях рекомендовалось работать именно через интерфейс, а сейчас есть два разных варианта.
Кстати, насчёт нежелательности использования CriticalSection в документации прописано, заменю на IMutex. И что-то виснет в 6.1 метод Wait из-под Win98...

---------------------------------------
C уважением,
Юрий Философов
1. А свойства клариных классов могут быть STATIC? Если да, то тогда эта критическая секция будет общей для всех экземпляров данного класса, и проблема решается.
Тогда - какая разница между такими "трейдовыми" классами и глобальным классом, общим для всех трейдов!?
2. CriticalSection - это плохо. И в MSDN это указано. Потому, что если внутри блока EnterCS-LeaveCS произойдет свал программы, то получаем дедлок, который лечится лишь рестартом всей системы.
Лучше использовать семафоры или мутексы - по крайней мере при смерти процесса, даржащего этот объект ядро его освобождает. А CS - не освобождает :(
Извини - но я не понял - какой дедлок? Чего?
Критическая секция синхронизирует доступ к обьекту между разними трейдами ВНУТРИ ОДНОГО ПРОЦЕССА!
Т.е. на другие процессы критическая секция НИКАК не влияет!
Именно ЭТИМ она и отличается от семафоров и мутексов.

А раз так, то критическая секция ВСЕГДА находится в пространстве памяти процесса, трейды которого она синхронизирует!
И, соответственно, при завершении такого процесса ЛЮБЫМ способом Винда автоматом деинициализирует всю память, занятую этим процессом - и уничтожит и критическую секцию.

Еще раз - использование критической секции НЕ БЛОКИРУЕТ какие-либо обьекты. Просто критическая секция выступает в роли "флажка", сотояние которого и используется при разрешении/запрещении доступа.
Т.е., если какой-либо трейд перед работой с переменной, например GLO:MembersList, установит блокировку с помощью критической секции, например GLO:MembersCS, то доступ к GLO:MembersList будет заблокирован ТОЛЬКО для тех трейдов, которые перед работой так-же будут использовать блокировку через GLO:MembersCS! Т.е., в данном случае использование GLO:MembersCS позволяет лишь узнать - кто-то уже использует для блокировки эту КС или нет?
И не более того! Если какой-либо трейд вообще не будет использовать КС перед работой с GLO:MembersList, то никто ему этого не запретит!

=============================
С уважением, Олег А. Руденко
Тогда - какая разница между такими "трейдовыми" классами и глобальным классом, общим для всех трейдов!?
Так отож.
Именно ЭТИМ она и отличается от семафоров и мутексов.
Кхм, насчет внутрипрцессовости я запамятовал, но см. ниже.
Еще раз - использование критической секции НЕ БЛОКИРУЕТ какие-либо обьекты. Просто критическая секция выступает в роли "флажка", сотояние которого и используется при разрешении/запрещении доступа.
Это понятно. Просто помнится ситуация, когда приходилось повисший поток срубать TerminateThread, а вход в критическую секцию был выполнен. Вот там и появлялся дедлок. Для мутексов, AFAIR, такого не происходит, хендл отпускается.

--
Best regards,
Maxim Yemelyanov
Написал: ClaList(2)
Ответить