Автор |
Тема: Подскажите (Прочитано 23023 раз) |
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Quote:| А в функциях [:CU] и [:AQ] переменной SP значение нигде не присваивается? |
|
Причина действительно кроется здесь...
НО ВНУТРИ ЭТИХ ВЫЗОВОВ НЕТ ПЕРЕОПРЕДЕЛЕНИЯ ПЕРЕМЕННОЙ SP.
Там только [GET *SP....]
Передается SP внутрь неявно.
Причина в самой конструкции
Если вместо
CALL MAKTMGPE_ (SP,DP,PR,[:CU],[:AQ])
Сделать
Z1=[:CU]
Z2=[:AQ]
CALL MAKTMGPE_ (SP,DP,PR,Z1,Z2)
То параметр передается корректно.
Первая запись несомненно удобнее, читабельнее и т.п., и используется у меня часто...а косячит далеко не всегда и по непонятным мотивам...
Сама функция, переданная в качестве параметра отрабатывает корректно...но ее влияние на другой параметр ...
Что делать?
С уважением, Владимир.
|
| « Изменён в : 10.06.11 в 14:48:17 пользователем: VLV » |
 Зарегистрирован |
|
|
|
Tupitsin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
Ищите и обрящете!
Я бы делал так (варианты):
1)
а)
Z2=[:AQ]
CALL MAKTMGPE_ (SP,DP,PR,[:CU],Z2)
б)
Z1=[:CU]
CALL MAKTMGPE_ (SP,DP,PR,Z1,[:AQ])
И смотреть, где будет ошибка. Диапазон поиска снижается вдвое.
2)В FARe найти все файлы со строкой SP=. И все просмотреть. Может быть, где-то есть несколько уровней вложенности вызовов процедур.
|
|
Зарегистрирован |
|
|
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Quote:Я бы делал так (варианты):
1)
а)
Z2=[:AQ]
CALL MAKTMGPE_ (SP,DP,PR,[:CU],Z2)
б)
Z1=[:CU]
CALL MAKTMGPE_ (SP,DP,PR,Z1,[:AQ])
И смотреть, где будет ошибка. Диапазон поиска снижается вдвое.
|
|
Обрадовался я вначале, что Дмитрий Дмитриевич про метод такой хороший напомнил
И в первом случае и во втором ошибка...
И общая процедура для этих вызовов отискалась...
И содержание у нее прозрачное...
И SP она НЕ переопределяет
И если вместо ее вызова разместить ее содержимое то НЕТ ошибки...
***********
:ACNT (PZ)
***********
IF [GET *PZ,'ACNT']=0
CT='10-00'
ELSE
CT=[GET *PZ,'ACNT']
ENDIF
RETURN (CT)
************
Но интересно что эта процедура в только в конкретном случае "крайней" оказалась...
Сделал "трассировку" переменной SP на фактах...
При возврате из второго вызова (если передача параметра явная) SP оказывается переопределенной.
Т.е. возврат из вызвавшей эту процедуру процедуры переопределяет SP.
После выхода из [:acnt pz] значение SP еще целехонькое...
А если вместо call acnt (pz) использовать call acnt
То нет ошибки...
Да и вообще acnt (pz) можно совершенно пустую сделать...ошибка останется...
|
| « Изменён в : 14.06.11 в 18:35:34 пользователем: VLV » |
Зарегистрирован |
|
|
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Вот...явил кажись внятную формулировку проблеммы...давайте уж помогать
Такая форма
***************************************
*FORMA
***************************************
SP='S01081697'
PZ='PZ1002'
CALL Z_ (SP,PZ,0,0,[:X SP,PZ])
333
SP ^SP^^^^^^^^^
PZ ^PZ^^^^^^^^^
GOTO END
***************************************
:Z_ (SP,PZ,CN,CO,Q)
***************************************
Z INP
SP ^SP^^^^^^^^^
PZ ^PZ^^^^^^^^^
--------------------
CALL SSS_ (SP,PZ,0,DS)
RETURN
***************************************
:SSS_ (SP,PZ,DQ,DS)
***************************************
SSS
SP ^SP^^^^^^^^^
PZ ^PZ^^^^^^^^^
---------------------
RETURN
***************************************
:X (SP,PZ)
***************************************
CALL Y (PZ)
X
SP ^SP^^^^^^^^^
PZ ^PZ^^^^^^^^^
------------
RETURN
***************************************
:Y (PZ)
***************************************
Y
SP ^SP^^^^^^^^^
PZ ^PZ^^^^^^^^^
------------
RETURN
***************************************
:END
******
Результат работы ФОРМЫ
Y
SP S01081697
PZ PZ1002
------------
X
SP S01081697
PZ PZ1002
------------
Z INP
SP PZ1002  ДОЛЖНО ТАК БЫТЬ ?
PZ PZ1002
--------------------
SSS
SP PZ1002
PZ PZ1002
---------------------
333
SP S01081697
PZ PZ1002
*****
А если вместо
CALL Y(PZ)
Написать
CALL Y(SP,PZ) (С соотв исправлением процедуры)
Работает как задумано
С уважением, Владимир.
|
| « Изменён в : 17.06.11 в 12:29:21 пользователем: VLV » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 865
|
on 14.06.11 в 18:21:12, VLV wrote:Вот...явил кажись внятную формулировку проблеммы...давайте уж помогать
Такая форма
***************************************
*FORMA
***************************************
SP='S01081697'
PZ='PZ1002'
CALL Z_ (SP,PZ,0,0,[:X SP,PZ])
...... |
|
В руководстве есть такое:
В опеpатоpе CALL можно указывать фактические паpаметpы подпpогpаммы - выpажение (или выpажения, pазделенные запятыми) в кpуглых скобках. Соответственно после опpеделения метки могут следовать фоpмальные паpаметpы подпpогpаммы - пеpеменная (или пеpеменные, pазделенные запятыми) в кpуглых скобках. Пpи входе в подпpогpамму фоpмальные паpаметpы получают значения фактических. Фоpмальные паpаметpы - это локальные пеpеменные подпpогpаммы, их экземпляpы автоматически уничтожаются пpи выполнении опеpатоpа RETURN. Паpаметpы пеpедаются "по значению", т.e. изменение значения фоpмального паpаметpа внутpи подпpогpаммы не влечет изменения значения фактического паpаметpа в вызывающей пpогpамме.
Похоже, что запись
CALL Z_ (SP,PZ,0,0,[:X SP,PZ])
синтаксически не предусмотрена именно при использовании CALL, т.к.
переписав в 2 строчки так:
X=[:X SP,PZ]
CALL Z_ (SP,PZ,0,0,X)
ситуация нормализуется.
Возможно следующие версии клиента будут сигналить о недопустимости подобных выражений.
|
| « Изменён в : 20.06.11 в 18:17:08 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Ну вот на 100% , Борис, не охота с этим соглашаться.
Ошибка возникает в ситуации когда внутри подпрограммы, получившей параметры явно, вызывается другая подпрограмма с другим кол-вом параметров и другими именами параметров...
все по букве мануала...
pr1 (sp,pz)
...
call pr2 (pz)
...
return
call pr2 (pz) не имея внутри себя кода, модифицируещего переменную sp, при окончании работы являет запорченной эту переменную.
Где здесь нарушение буквы мануала?
Иметь ввиду что мог накосячить в каком нить другом вызове..при том что сам этот вызов корректно отработал....а где гарантии что и других неочевидных влияний нет?
А вообще очень хочется чтобы мануал начал допускать такого рода запись...
(Дефакто она ведь работает, не знаю уж как разработчик задумывал)
CALL Z_ (SP,PZ,0,0,[:X SP,PZ])
Это очень сильно сокращает количество кода и повышает читабельность, что полезно для здоровья ФБП
С уважением, Владимир.
|
| « Изменён в : 23.06.11 в 14:35:57 пользователем: VLV » |
Зарегистрирован |
|
|
|
Tupitsin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
Я согласен с Владимиром. Формально такая запись абсолютно корректна. Более того она работает. Но не всегда. Попробуйте в программке, присланной Владимиром, заменить определение (и, соответственно, вызов)
Y (PZ) на
Y (SP,PZ)
Ошибка исчезнет.
Попробуйте закрыть вызов Y
*CALL Y (PZ)
ошибка исчезнет.
Хотя в обоих случаях вызов Z_ останется тем же.
Вообще-то это уже вопрос к Аркадию.
Надо править либо сервер, либо описание, где надо точно описать исключения из правил вызова вложенных процедур.
|
| « Изменён в : 24.06.11 в 09:17:06 пользователем: Tupitsin » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 865
|
Согласен, но поупражняйтесь с кол-ом параметров в вызовах подпрограмм из функций, которые параметрами в первом вызове, не забудьте про return(..) - там ещё "чудеснее" будет.
На сегодня, исключив запись вызова функции в параметрах call всё должно работать "как договорено".
Если есть пример глюка без этой записи пропишите пожалуйста, ещё поупражняюсь.
P.S.
local - это сила, пользую и всем рекомендую, а
[:SUB ..] и call SUB () до сих пор у меня в стороне.
|
|
Зарегистрирован |
|
|
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Подскажите плз...
Существует ли возможность зарегистрировать операцию в нужном месте ЖО в соответствии с конкретной датой и временем?
С уважением Владимир.
|
|
Зарегистрирован |
|
|
|
BBBB
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 89
|
Не совсем понятно - надо вносить в прошлое, в текущий месяц или в будущее, это должно произойти при каких-то условиях или еще как?
|
|
Зарегистрирован |
|
|
|
VLV
Я люблю Финансы без проблем!
Просмотреть Профиль |
Сообщений: 231
|
Вносить нужно в прошлое.
Есть файл с транзакциями продаж от ККМ. В транзакциях есть дата и время. При загрузке этого файла в ФБП сервер регит операции в указанный день, но размещает их в дополнение к существующим операциям. А интересно разместить их не только в нужную дату, но и в нужное время.
|
| « Изменён в : 11.08.11 в 16:46:45 пользователем: VLV » |
Зарегистрирован |
|
|
|
Tupitsin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
Когда-то, лет 5 назад, у меня было предложение к Аркадию сделать возможность вводить операцию ПЕРЕД (или ПОСЛЕ, или то и другое) операции с заданным кодом. Такое добавление решило бы многие проблемы. К сожалению, предложение не нашло поддержки. Конечно, вручную можно проделать такой финт, но это ОЧЕНЬ трудоемко. И уж точно не средствами сервера.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 865
|
on 12.08.11 в 09:24:31, Tupitsin wrote:| Когда-то, лет 5 назад, у меня было предложение к Аркадию сделать возможность вводить операцию ПЕРЕД (или ПОСЛЕ, или то и другое) операции с заданным кодом. Такое добавление решило бы многие проблемы. К сожалению, предложение не нашло поддержки. Конечно, вручную можно проделать такой финт, но это ОЧЕНЬ трудоемко. И уж точно не средствами сервера. |
|
Не помню, кто делал это предложение первым, но был ответ, что здесь может быть накладка, т.к. возможна ситуация запроса от более одного клиента на регистрацию операции за выбранным штампом и потом гарантировать неизменность желаемого состояния относительного положения операций будет проблематично в общем случае.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 865
|
on 11.08.11 в 16:45:35, VLV wrote:Вносить нужно в прошлое.
Есть файл с транзакциями продаж от ККМ. В транзакциях есть дата и время. При загрузке этого файла в ФБП сервер регит операции в указанный день, но размещает их в дополнение к существующим операциям. А интересно разместить их не только в нужную дату, но и в нужное время. |
|
Если эти действия Вы планируете делать эпизодически, т.е. раз от разу при необходимости, то решение может быть таким:
- поднимаете за требуемый день операции;
- добавляете операции от ККМ;
- делаете сорт по времени;
- удаляете старые, а лучше перерегистрируете на имеющиеся и добавляете оставшийся хвост.
Почему ККМ не может сразу бомбить в ЖО?
P.S. Вам ещё надо будет выставить синхронно время на севрере и ККМ
|
| « Изменён в : 12.08.11 в 10:09:00 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
Tupitsin
Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
on 12.08.11 в 09:54:07, Boris, Kiev. wrote:
Не помню, кто делал это предложение первым, но был ответ, что здесь может быть накладка, т.к. возможна ситуация запроса от более одного клиента на регистрацию операции за выбранным штампом и потом гарантировать неизменность желаемого состояния относительного положения операций будет проблематично в общем случае. |
|
Если придет запрос на регистрацию от 2-х, 3-х... клиентов, то они будут разбираться только между собой, кто раньше, а кто позже. Однако, ВСЕ эти операции лягут ПЕРЕД (ПОСЛЕ) заданной. Не вижу конфликтов.
|
|
Зарегистрирован |
|
|
|
|
|
