If, for example, I want a uedll to change a field to 'read only' status upon a save, can that be done ?

I haven't seen anything trying to search for protect or read only here.

These are custom fields so no worries about other processes interfering with them ...

Thanks,

JMM.

Not sure what you mean by uedll, but I have used attr.input in 4c4 to flip a field for entry. I think I get update.status or something like that. I am not sure if that is what you are looking for if this is something different.

Not sure what you mean by uedll, but I have used attr.input in 4c4 to flip a field for entry. I think I get update.status or something like that. I am not sure if that is what you are looking for if this is something different.

Hello Mark,

i think "uedll" is "user exit" .?
(TABLENAMEue (e.g. tisfc001ue))

attr.input in B4 is disable.fields in LN and is done in sessionscript.

User Exit :

Overview

A User Exit DLL (UEDLL) is a DLL that will reside outside the standard software. It will have the same name as a standard DAL with the extension 'ue' (for 'user exit'). E.g. 'whinh200ue' for table whinh200. Customers can implement a UEDLL in order to be able to define extra business logic before and after the standard 'before' and 'after' handling of saves and deletes, by means of specific hooks that will be executed by the 4GL engine and/or DAL Engine. In this way it is possible to e.g. conditionally publish data changes to the outside world.

Interaction with 4GL Engine / DAL Engine

When present, the User Exit DLL for a certain table will be loaded by the 4GL engine/DAL Engine by the time the DAL for this particular table will be loaded. In situations where no DAL is present this will be the moment at which a DAL would be loaded if it existed. This means that there is no need to have a DAL in order to make use of the UEDLL.

Preconditions

A DLL becomes a UEDLL when it meets the following conditions:

Its name is consisting of the table code with 'ue' as suffix, like whinh200ue
It includes bic_dal, as follows: #include <bic_dal>
Restrictions

A UEDLL is treated like a regular DAL. This means all kind of DAL related functionality can be used, like:

Function with.old.object.values.do()
Function with.object.set.do()
Pre-defined variable subdal
Note however that the following restrictions apply:

Business methods cannot be implemented in a UEDLL Instead the business logic should be programmed in another (separate) general DLL.
It is strongly discouraged to define other external functions in a UEDLL and link the UEDLL directly to other scripts. Instead, use a normal general DLL. (This also applies to regular DALs).
User Exit Hooks

A UEDLL script can contain the following hooks:

ue.before.before.save.object()
ue.after.before.save.object()
ue.before.after.save.object()
ue.after.after.save.object()
ue.before.before.destroy.object()
ue.after.before.destroy.object()
ue.before.after.destroy.object()
ue.after.after.destroy.object()


Regards

Thanks Bernd. I was going off the profile and the last post for DFE also said 4c4. Had a feeling this was ln or later than 4c4 version.

We are still IV but we are transitioning to LN ...

My User Exit DLL contains some basic code to change values upon things that the user does in the session.

I was hoping to default the values to a read only state in the table defs but appears I cant do that, bummer.

So, Next I was hoping the say :
If user select this certain field, then make these other fields non editable or

Hide the fields as default. If user selects soemthing, then make those fields show up ... something like that .....

I am not very sophisticated on my coding abilities . I will look up about that attr.input

Well of course my uedll in LN gives me the "Unresolved Reference to Function 'disable.fields'" error.

The problem is I don't know what or how to even find out what #include I need in my scripting. I assume it is an Include that is missing .....

How do i find this out within the reference guides etc ? It seems a big mystery .... !

Well when I read the help on the board it seems like it was a 4gl function and an include would not be needed. The above mentions #include <bic_dal> - but I have no clue about LN stuff and probably should not even post.

User exits have limitations to limited to executing database related activities around events where a record is added, updated, or deleted - replacing pre-LN main.table.io sections. You cannot interact with the user interface (forms/fields/groups) since you are executing a script that interacts with the table (like DAL) instead of the user interface (DAL2). I don't know if FP8 stretched the abilities of UE scripts, yet.

Be very careful when changing fields within the table involved with the UE (the UE name) since the change this late in the process will not execute standard DAL functions around the field. Always try to use DAL to update other tables from within the UE script but try to ensure that the table being updated doesn't update the table associated with the UE script, causing an infinite DAL/UE loop.