RS
У тебя в каком месте кода происходят задержки? Вот там и нужно вставлять синхронайз, а не в конце расчетов перед освобождением потока
Далее непонятно, почему ты закомментил освобождение экземпляров класса в процедуру Execute.
Size: a a a
2020 November 27
RS
Далее непонятно, почему ты закомментил освобождение экземпляров класса в процедуру Execute.
Также. Если ты создаешь объект внутри процедуры и освобождаешь там (или нет), то переменные лучше сделать локальными внутри процедуры. Если же они могут понадобится где-то еще в классе, то ok. Но все равно интуитивно что-то не то у тебя здесь
СП
Синхронайз периодически должен быть установлен в таком месте, где бы он периодически ызывался. А у тебя он вызывается в конце расчета. Зачем? Если и так потоки скоро закроются и ты сможешь все обновить
Все данные из потока нужны после всех вычислений. Понял, синхронайз не нужен. Данные из потока передать в основной поток через объект=поля потока?
VA
проперти нужны когда могут появиться сеттеры\геттеры (наврятли светит в простом обменном интерфейсе), публишед надо чтобы инфа была доступна в ртти для например автосериализации (это в принципе может произойти с данным форматом, если потребуется загрузить\сохранить). нет?
не сказу за fpc, но в delphi в управляется директивами, что попадет в rtti
и published в первую очередь был сделан для сериализации свойств компонентов (dfm, Object Inspector)
и published в первую очередь был сделан для сериализации свойств компонентов (dfm, Object Inspector)
z
не сказу за fpc, но в delphi в управляется директивами, что попадет в rtti
и published в первую очередь был сделан для сериализации свойств компонентов (dfm, Object Inspector)
и published в первую очередь был сделан для сериализации свойств компонентов (dfm, Object Inspector)
а инспектор\дфм разве не на ртти?
VA
а инспектор\дфм разве не на ртти?
на ртти
z
на ртти
дак я про тоже
RS
Сергей Пятыгин
Все данные из потока нужны после всех вычислений. Понял, синхронайз не нужен. Данные из потока передать в основной поток через объект=поля потока?
Понятно. То есть синхронайз просто для передачи данных, а не для обновления данных на форме? Ну можно это сделать в ивенте потока ондестрой тогда
СП
Далее непонятно, почему ты закомментил освобождение экземпляров класса в процедуру Execute.
Не осознал как убрать ту самую ошибку с исчезновением данных в объекте из за преждевременного высвобождения.
VA
дак я про тоже
моя мысль была в том, что rtti не ограничивается только элементами published секции
СП
Понятно. То есть синхронайз просто для передачи данных, а не для обновления данных на форме? Ну можно это сделать в ивенте потока ондестрой тогда
Да, для передачи данных, гуи обновлять не надо, пока...
RS
Сергей Пятыгин
Не осознал как убрать ту самую ошибку с исчезновением данных в объекте из за преждевременного высвобождения.
Че за преждевременное освобождение? Можешь кинуть подробности ошибки? Вообще нужно ехать. Потом может глян
СП
Также. Если ты создаешь объект внутри процедуры и освобождаешь там (или нет), то переменные лучше сделать локальными внутри процедуры. Если же они могут понадобится где-то еще в классе, то ok. Но все равно интуитивно что-то не то у тебя здесь
Да, сам чувствую не то.
СП
Че за преждевременное освобождение? Можешь кинуть подробности ошибки? Вообще нужно ехать. Потом может глян
СП
А все таки как правильно, доступ к классу делать в виде свойств или через публичные поля, если с полями никаких манипуляций внутри класса не делают?
VA
Сергей Пятыгин
поток продолжает работать, а класс с данными уже разрушен.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
СП
поток продолжает работать, а класс с данными уже разрушен.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
Спасибо, но интересует не простое решение, а как это вообще эту идеологию=архитектуру сделать правильно?
VA
Сергей Пятыгин
А все таки как правильно, доступ к классу делать в виде свойств или через публичные поля, если с полями никаких манипуляций внутри класса не делают?
вопрос риторический.
более правильно с точки зрения ООП, контролем за доступом в данным класса, учитывая возможную доработку классов в дальнейшем и тд использовать именно свойства.
но если прям вообще ничего такого не планируется, то и с полями будет норм работать
хотя я тоже сам не стал бы заменять свойства на поля при условии, что это публичный класс
более правильно с точки зрения ООП, контролем за доступом в данным класса, учитывая возможную доработку классов в дальнейшем и тд использовать именно свойства.
но если прям вообще ничего такого не планируется, то и с полями будет норм работать
хотя я тоже сам не стал бы заменять свойства на поля при условии, что это публичный класс
СП
поток продолжает работать, а класс с данными уже разрушен.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
как самое простое решение в данном случае - переложить ответственность за удаление классов-данных потоку.
И еще не совсем понятно, если пойти по простому варианту, они же инициализированы в процедуре и их не видно в потоке:
procedure TFormMain.CalculateClick(Sender: TObject);
var
j: Integer;
GetSM: TGetSystemMagnetic;
...VA
Сергей Пятыгин
И еще не совсем понятно, если пойти по простому варианту, они же инициализированы в процедуре и их не видно в потоке:
procedure TFormMain.CalculateClick(Sender: TObject);
var
j: Integer;
GetSM: TGetSystemMagnetic;
...ничего не меняется, если ты делегируешь разрушение объектов потоку