Если возможно, дополните компонент Dir выводом значений в точку onEnd (как в DirTools точки doExists-onOK) или событием onError (как в FileAttributes) в случае неудачи при создании папки.
Этот топик читают: Гость
Ответов: 356
Рейтинг: 31
|
|||
карма: 0 |
|
Разработчик
Ответов: 26304
Рейтинг: 2146
|
|||
olDjeka писал(а): дополните компонент Dir выводом значений в точку onEndА вот теперь предположим, что кто-то ипользует пустое событие выхода (да мало ли для чего), а мы ему на выход данные подадим, нарушится работоспособность схемы. И чел будет долго искать, а где же у него ошибка, вроде, раньше работала. Вот потому, такое добавление, в плане совместимости, нежелательно ------------ Дoбавленo в 10.12: olDjeka писал(а): или событием onErrorА вот это, вполне возможно. Но, опять таки -- если кто-то использует событие onEnd при любом результате создания, если поставить условие удачно/неудачно, то опять нарушиться совместимость. А ставить два события, onError и onEnd, тоже неправильно. Вывод: оставляем все "как есть", если только руководство не предложит другой вариант |
|||
карма: 22 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
nesco писал(а): А вот теперь предположим, что кто-то ипользует пустое событие выходаСчитаю, что olDjeka прав. nesco писал(а): нарушится работоспособность схемы. |
|||
карма: 25 |
| ||
Голосовали: | olDjeka |
Разработчик
Ответов: 26304
Рейтинг: 2146
|
|||
Tad писал(а): если хорошо подумать, то работа старой, правильно созданой схемы, не нарушится и совместимость не пострадаетНарушиться. Читаем внимательно nesco писал(а): если кто-то использует событие onEnd при любом результате создания, если поставить условие удачно/неудачно, то опять нарушиться совместимость. А ставить два события, onError и onEnd, тоже неправильноИ я знаю схему, где это нарушиться. Все. На этом дебаты по этому вопросу закрываем до ответа руководства ------------ Дoбавленo в 11.31: Мое мнение такое, что перестаем добавлять в компоненты разные мелкие фичи на каждый чих, каждого пользователя, раньше прекрасно обходились и без них, обойдуться и сегодня. Кому надо, тот возьмет себе и добавит |
|||
карма: 22 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
nesco писал(а): перестаем добавлять в компоненты разные мелкие фичи на каждый чих, каждого пользователяЭто конечно очень верно и по нашему, не проверив на удачно/неудачно, выполнять программу дальше. nesco писал(а): И я знаю схему, где это нарушиться. |
|||
карма: 25 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
совместимость нарушится только в том случае, если ForceDirectories выдает ошибку при попытке создать путь, который уже существует. В противном случае такой код:
|
|||
карма: 27 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
А я думал так.
И никому этот путь не повредит. Ну не смог я придумать ситуацию, где бы это смогло случиться. |
|||
карма: 25 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
а это уже нарушение совместимости. Самое непосредственное причем.
|
|||
карма: 27 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
Tad писал(а): Ну не смог я придумать ситуацию, где бы это смогло случиться |
|||
карма: 25 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Tad, мне(да и nesco, тоже) кажется совершенно очевидным тот факт, что выдача в поток чего угодно на какую угодно точку любого элемента ведет к нарушению совместимости с частью схем. Пример этой банальной ситуации даже не ловко приводить тем более человеку со стажем 5 лет работы
code_16567.txt |
|||
карма: 27 |
| ||
файлы: 1 | code_16567.txt [363B] [177] |
Ответов: 16884
Рейтинг: 1239
|
|||
Да на пример даже неловко смотреть
![]() Только не надо говорить, что в первом случае будет событие пустое, а в моем выдаст путь. Я это знаю. И то что всем последующим компонентам схемы этот путь по барабану тоже знаю. Tad писал(а): если хорошо подумать, то работа старой, правильно созданой схемы, не нарушится и совместимость не пострадает. P.S. Обзывать и стыдить не надо. Просил четкий пример у nesco, который nesco писал(а): И я знаю схему, где это нарушиться. Я тоже хочу знать эту схему. |
|||
карма: 25 |
|
Разработчик
Ответов: 26304
Рейтинг: 2146
|
|||
Dilma писал(а): совместимость нарушится только в том случае, если ForceDirectories выдает ошибку при попытке создать путь, который уже существуетВ VHiUpdate выход onEnd используется всегда (да и не в нем одном), в случае попытки создать папку, которая уже есть это событие используется для дальнейшего копирования, просто, как источник события, и ничего более, предполагая, что папка уже есть, независимо, что создана она сейчас или вчера. Для совместимости предложенной схемы с вашим логическим вариантом, необходимо будет во всех таких схемах соединить две точки в один поток (onEnd и onError), что есть прямое нарушение совместимости большинства, ранее созданных, схем. Я, категорически против такого подхода, есть для этого компонент DirTools, вот его и используйте для проверки наличия папки, и, если ее нет, то создавайте, если не устраивает штатный подход |
|||
карма: 22 |
|
Ответов: 16884
Рейтинг: 1239
|
|||
nesco писал(а): В VHiUpdate выход onEnd используется всегда...предполагая, что папка уже есть А я предполагаю (слово то какое успокаивающее ![]()
nesco писал(а): Я, категорически против такого подхода![]() |
|||
карма: 25 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Tad писал(а): Да на пример даже неловко смотреть = в любом случае (в этом примере) в If_else событие False и никогда не True.Вы издеваетесь коллега? Пример показывал типичную ошибку при сравнении любого значения с NULL, нулем или пустой строкой. Судя по коду ForceDirectories разделение на onEnd и onError отменяется. |
|||
карма: 27 |
|
Разработчик
Ответов: 26304
Рейтинг: 2146
|
|||
Cамое большое, что можно сделать, так это только вот так, тогда не будет нарушена совместимость ни с чем, хочешь, используй onError, хочешь -- onEnd. Если руководство не найдет ничего поротиворечивого в коде, то я его добавлю
|
|||
карма: 22 |
| ||
Голосовали: | olDjeka |