spartacus
26th March 2007, 13:54
Since BaanERP the "check.input" subsection shouldn't work anymore for table fields.

I habe now a session which uses tdpur401 as main table. Only for this session I have to restrict input for some fields.

Because there is an existing DAL I have to use a property hook to check input. But due to the fact that tdpur401 is called from a lot of sessions, I have always to check which program the DAL calls. IMHO in that case a lot unnecessary code, which doesn't help to keep scripts readable.

Isn't there still an other way, to check restrictions in the GUI-script?

bigjack
26th March 2007, 19:13
HI,

Have you tried something like,

field.xxxyyyzzz
on.input:
if not valid_input() then
input.again()
endif


I think it should work.

Cya

spartacus
27th March 2007, 10:27
Hi bigjack,

thank you for that hint. I thougt about realizing it that way. But at least I decided to do the validation in the DAL with check of the current prog-name, even if I dislike the "complexity" of this solution!

Im always unsure, using the inputsections for validation. Isn't it possible to trick that kind of validation with consequent use of the mouse? I mean is it sure that the validation always run if one does an input to the field, and select another field with the mouse? Or is this only a problem in "after.input" ?


greetings

MariaC
27th March 2007, 14:14
Be careful of using the progname in a DAL. My experience is that it doesn't work properly as the dal seems to be activated by the first program that uses is and it will always keep that program name.

spartacus
27th March 2007, 14:51
Hi Maria,

thank you for that hint! A typical thing one can lose sight of!!

What do you mean with program name? The variable "prog.name$"?

I did it that way: I declared an "extern" variable: "session.name" in GUI-Script and DAL. In the GUI-Script I assigned a value to that variable and in the DAL I checked it. Is it the same approach where you get problems with?

Leerkes
27th March 2007, 21:21
Hi there,

If you check table fields and the table has a dal, then indeed the check.input sections for the table fields are ignored in the UI scripts. The check.input sections are only called for non-main table form fields.

It depends on the type of DAL how the check has to be programmed. In DAL2if a table field cannot be empty, then that should be programmed in the is.mandatory() hook. The rest should be put in the is.valid() hook.

If a check is depending on the UI script (or anything else) that is triggering the DAL, then the only thing which you can do is introduce a global variable in the DAL which indicates whether the DAL is called from that particular situation. So let's say we introduce in the DAL the following global variable:
boolean g.triggered.from.my.ui

Then introduce in the DAL 2 business methods with which you can put that global variable to true and one to false.

function extern long tablexxx.dal.is.triggered.from.my.ui()
{
DLLUsage
EndDLLUsage
g.triggered.from.my.ui = true

return(0)
}

and another function to put that global variable to false, although you are probably not going to use that one. Then in the UI do a dal.start.business.method("tablexxxx", "tablexxx.dal.is.triggered.from.my.ui", long.ret) to put that variable to true. In the checks in the DAL etc. you can then depend the check on the global variable g.triggered.from.my.ui you introduced.

I hope this is of some help.
Regards,
Michiel

spartacus
28th March 2007, 14:49
Michiel,

this is what I actually did. But I'm still a little unsure if the "global variable" in all instaces is treated right.

Leerkes
29th March 2007, 09:14
Hi Spartacus,

I used this method a couple of times and it is a good way to make your dal react differently to specific UI scripts.

Regards,
Michiel

spartacus
29th March 2007, 09:53
Hi Michiel,

I also did some tests with that solution. I paid special attention how parallel instances of the DAL react. Everythings seems to be fine.

So things seem to be fine.

Thank you for your support