Переменные в наследнике класса

[Lemming]

Цитата:

Сообщение от longson

Значит проблема может именно где в вызове pack() и unpack() из основного класса.

Четко объяснить не могу, надо ставить эксперимент и все внимательно смотреть. Однако, на сколько я понял наступая на похожие грабли, методы pack() и unpack() некоторым образом (прям все загадками получается ) влияют на обмен данными между клиентом и сервером в классах - наследниках RunBase.

p.s. Возможно кто-то более фундаментально объяснит.

[longson]

Цитата:

Сообщение от Lemming

Четко объяснить не могу, надо ставить эксперимент и все внимательно смотреть. Однако, на сколько я понял наступая на похожие грабли, методы pack() и unpack() некоторым образом (прям все загадками получается ) влияют на обмен данными между клиентом и сервером в классах - наследниках RunBase.

Ага, у меня такое же ощущение. Переменная теряет значение в строке кода, где написано типа if(ClientServer::....) (насколько я помню : ) ).

Цитата:

Сообщение от Lemming

p.s. Возможно кто-то более фундаментально объяснит.

И это здорово. Я не совсем разобрался с этими методами, хотя уже нашёл достаточно много обсуждений здесь по ним. Каждый раз использую, просто взял из готового и поставил в свой класс

[kashperuk]

Вообще варианта 2, но попробую показать на одном из них. (картинки с обоими вариантами prompt в классах RunBase неоднократно пробегали на форуме и даже есть в директории аксапты)

    // Move prompt to client when running on server and the class is swappable
    if (isRunningOnServer() && this.canSwapBetweenCS() && this.canSwapBetweenCSPrim())
    {
        [clientPrompt,clientPacked] = runbase::promptOnClient(classidget(this),this.promptPack());
        this.promptUnpack(clientPacked,clientPrompt);
        return clientPrompt;
    }

Вот собственно этот код есть в методе promptPrim класса RunBase
Как видим, вызываются последовательно promptPack и promptUnpack, которые в свою очередь вызывают pack и unpack класса.

То есть, когда класс исполняется на сервере, параметры в диалог попадают через те же методы, что и обычно. Но, соответственно, для того, чтобы они вернулись из диалога, они должны сохраняться в методе pack()

[AndyD]

Может, у вас вот это срабатывало в классе LedgerInAccountStatement?

public void getLast()
{
    super();

    if (!WinAPI::showMruAllowed())
    {
        filename = '';
    }
}

(!WinAPI::showMruAllowed()) == true ?

[miklenew]

public boolean getFromDialog()
{
    #Banks_REP
    ;

    bankAccountId = dialogBankAccountId.value();
    filename      = #DirectoryAbsolutIBank;
    return true;
}

А мне вот что осталось не понятным.
В наследнике и родителе есть по методу getFromDialog в каждом
В родителе
filename = dialogFilename.value();
В наследнике
filename = #DirectoryAbsolutIBank;
Интересно как сам класс запускается? Я то его немного почикал чтоб диалог появился. Но у меня с сохранением всё вышло Ок.
И второй вопрос зачем на диалог выводить поле чтоб в getFromDialog подменить значение выбранное пользователем. Не знаю точно, но процентов на 90 кажется это не глюк.

[miklenew]

Цитата:

Сообщение от AndyD

Может, у вас вот это срабатывало в классе LedgerInAccountStatement?

public void getLast()
{
    super();
    if (!WinAPI::showMruAllowed())
    {
        filename = '';
    }
}

(!WinAPI::showMruAllowed()) == true ?

Оно срабатывает до появление диалога. Поэтому без разницы. Ему интересно что происходит когда нажали ок.

[longson]

@miklenew

Ситуация такая:

В основном классе реализуется диалог, который даёт пользователям возможность каждый раз при импорте выписки из банка выбирает файл, из которого и взята информация. Кроме того, там была деактивизирована возможность выбора банковского счёта, и много ещё другое.

Как я написал здесь Работа с классом AsciiIO при выборе пользователем файла есть проблема места выполнения метода обработки, он принимает, например \\web\abc.txt , но не принимает c:\abc.txt, хотя это один и тот же файл, потому что он выполняется на сервере. Поэтому решил прямо определить место сохранения текстового файл на сервере и таким образом пользователь не должен ничего выбирает кроме банковского счёта.

Основной класс не хотелось бы много трогать. Поэтому решил так и делать, в наследнике пишу отдельный метод dialog без super() и там добавил, удалил что угодно. И соответственно getfromdialog() тоже так делал. При запуске точно этот метод в наскледнике и вызывается. Я вижу это в стеке.

[miklenew]

Это \\web\abc.txt или это c:\abc.txt контролу по барабану. Хоть напишите там поздравления с новым годом. Или что-то я вас не пойму.
А если уж решили жёстко путь забить то лучше в метод dialog() наследника
Впишите это
filename = #DirectoryAbsolutIBank;
Тогда уже на диалоге появиться ваш путь, а не после.
А так шаманство какой-то. В диалоге одно, а потом где-то другое. Как пользователю обьясните чё куда.

[longson]

А так пользователю ничего не нужно объянить . Посморите в наследнике, там в перекрываемом диалоге есть строки

dialogFilename.active(false);
dialogFilename.visible(false);

Конечно можно и в диалоге написать filename, однако я так думаю что в getfromdialog() написать т.е есть доля логичности ведь именно здесть переменная принимает значение. Но в этом случае эффект будет один и тот же.

По файлам, более подробно объясняю

Вот этот файл abc.txt находится на диске C:\ на локальном компьютере, тот же файл скопировал на диск \\web\data\abc.txt

Так, метод обработки файла выполняется на сервере, то если в качестве константы #DirectoryAbsolutBank написал "C:\\abc.txt", он обращает на диск С на сервере, а не на локальном компьютере, поэтому он ничего не видит там.

А если указать #define.DirectoryAbsolutBank(\\\\web\\data\\abc.txt), т.е сетевой путь, то всё равно где метод выполняется, он всегда найдет нужный файл, да если там физически он и есть.

Вот если дать пользователям возможность выбрать файл, и файл находится на его компе, допустим называется COMP, папка называется DATA, расшяренный, то трудноватно объяснить ему, что \\COMP\DATA\abc.txt и C:\DATA\abc.txt - это одно и то же, но нам нужно именнно первый

[miklenew]

1) Ваш класс это операция импорта. Это значит берём откуда то в себя. Т.е. Полюбому как не крути должен быть явным этот путь. А не тогда когда забыли просим программиста посмотреть от куда.
2) Кроме visible есть enable. Если хотите защиту от кривых рук используйте. Но не рекомендую. Если человек зашёл и не знает для чего это он никогда трогать не будет. Тем более ответственный человек. А не ответственный такую процедуру запускать не будет. Ему же потом с этими данными работать. Можно в принципе и на ключ повесить кнопку по которой вызывается процедура.
3) Кроме того обяснить про относительный и абсолютные пути не так уж и сложно. Я уверен какой бы человек деревянный не был. Ему это понадобиться и в других случаях. Потомо что то это основы Windows. Прописывать эти пути может он даже не будет никогда, но видя их не будет задовать лишних вопросов.
4) Первоначально проблема была, что переменная сохраняющая значения контрола не адекватно себя ведёт. Прописав в main наследника вызов promt и run. Этого достаточно, чтоб вызвать диалог. А в run закоментировав обработку. И поставив в run info(filename). Запустил класс набрал путь в контроле и ok. Я получил в info то что мне нужно.
Итого: я понимаю пути программера не исповедимы и решения как и чё писать за вами. Но вы спросили и тут уже люди начали вспоминать возможные глюки. Но вот в данный момент я повторяю на 90 % уверен глука нет. Если справились прописыванием в classdeclaration наследника ещё один раз сохранение ок. Можете остановиться. Но это криво (не очень но криво) и не разобравшись сейчас у вас таких классов будет очень много дальше.
Да, может не в тему. Просто иногда вижу, что люди убирают статические глобальные переменные в макрос как у вас Banks_REP. Если знаете зачем скажите пожалуйста. Мож тоже буду пользоваться. Неужеле не проще в коде написать а="гы-гы-гы";. Потом просматривая код нагляднее выходит.

[kashperuk]

Цитата:

Сообщение от miklenew

Да, может не в тему. Просто иногда вижу, что люди убирают статические глобальные переменные в макрос как у вас Banks_REP. Если знаете зачем скажите пожалуйста. Мож тоже буду пользоваться. Неужеле не проще в коде написать а="гы-гы-гы";. Потом просматривая код нагляднее выходит.

BestPractice.
Причем не только Аксаптовский, а вообще языков программирования касательно констант. И кстати, читается, имхо, лучше через макро-объявление.
и всегда знаешь. где можно найти его значение чтобы посмотреть.

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

[miklenew]

Цитата:

Сообщение от kashperuk

BestPractice.
Причем не только Аксаптовский, а вообще языков программирования касательно констант. И кстати, читается, имхо, лучше через макро-объявление.
и всегда знаешь. где можно найти его значение чтобы посмотреть.
а если переменная будет - и решит какой-нить чудо программист, что ее значение должно быть не "гы-гы-гы", а "Г". вот тогда и возможно гы-гы-гы, когда перестает работать и непонятно куда копать, потому что в наследнике кто-то что-то тупое написал.

Мысль не уловил. Константы вообще редко в Axapte нужны. Хотя если подумать, то в константы можно запихнуть всё что угодно даже тексты info. И даже видел это. У нас вот на позопрошлой работе было как. Есть какая-нибудь ошибка. Есть задача от пользователя: вот не могу сделать то-то, появляется ошибка и текст. Ситуацию воспроизвести врятли удастся, но по тексту сообщения и зная на что жмёт. Т.е. класс и родители пускаем поиск и очень часто находим это место и не лезем в макросы. Последнее веяние было: В конце info номер модификации ставить в скобках. Чтоб если выскачила сначало посмотреть описание задачи, мож уже на этом этапе вопрос отпадёт почему, что не так. А потом программеру.
А насчет что кто-то поменяет "гы-гы-гы" на "Г", ничего не измениться от того в макросе это или в коде.
Насчёт других языков согласен очень оправдан подход объявлять в одном месте. Потому что в них константы очень часто используются. Но в Axapte зачастую наблюдаю одно объявление, одно использование.

[AndyD]

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