tags:

views:

282

answers:

2

I've created a custom lookup form in Axapta 3.0 in which a user can select an OprId from a ProdRoute datasource. Before displaying the lookup the ProdId is set and may not be altered by the user. The user may only select an OprId from the ProdRoute of the production order with the valid ProdId. According to documentation, one can prevent the user from altering the query by locking the range. I've done so like this:

qbrProdId.value(queryValue(_prodId));
qbrProdId.status(RangeStatus::Locked);

Here qbrProdId is a variable of type QueryBuildRange and _prodId specifies the ProdId.

When the lookup is displayed and the user tries to change the filter the ProdId is locked. Good. However, when the user presses Ctrl+F on the ProdId field of the lookup, or if the user clicks on Search on the toolbar a different ProdId can be entered.

How can I prevent this?

I've thought of changing the ProdId field in the grid of the lookup to be of type "Display" instead of being a datasource field. But isn't there a better solution for this?

(By the way, the query is not automatically created but created manually in the "init" method of the form datasource).

A: 

Just use a dynalink instead of range.

HTH

Velislav Marinov
As stated, the query is manually created. This is needed for the method findValue() to work properly. A dynalink is out of the question.
_pointer
+1  A: 

OK, than you can just override the task() method. This should disable the filter functionallity on the lookup form.

public int task(int _taskId)
{
    int ret;

    switch(_taskId)
    {
        case 2855:
        case 2844:
        case 2837:
        case 799:
            return 0;
    }

    ret = super(_taskId);

    return ret;
}
Velislav Marinov
Thanks for your answer Velislav. Your approach to the solution is right. However the only correct taskid for my problem is 779, which is not in your example. I've found this value with the debugger. The taskid's 2844, 2837 and 799 all appear in the Task macro, but 779 doesn't. This amazes me. Where is this value documented then? The value 2855 also is not part of the Task macro. So it appears there are more valid taskid's than those that can be found in the Task macro? A disadvantage of your solution is that all fields are disabled. I ended up using a display method for the specific field.
_pointer
Yes, I think that some of the TaskIds are not included in the macro. I tried this code on AX 4 and 5 and the value that worked for me was 2855. Unfortunately I don't know of any documentation for this.
Velislav Marinov

related questions