Hi, here’s my problem: I have a field in a table, say Table1.Field1, which is related to the primary key of an other table (Table2). The TableRelation property just points to Table2. In Table1.Field1 OnValidate trigger there is the code: Table2.GET(Field1); ... (populates some other fields) In OnLookup trigger: IF FORM.RUNMODAL(0,Table2) = ACTION::LookupOK THEN Field1 := Table2.Field1; VALIDATE(Field1); Nothing very smart, but not even so weird, I think. Whenever a lookup on Table1.Field1 is performed the expected form opens, but never on the expected record. Sometimes the cursor points to first record in the table, sometimes to the last one looked up, sometimes on the next to the one looked up… It’s driving me crazy! [B)] Anybody has an idea? Anna
Your code will only work if you type into Field1 and then press Lookup - without leaving the record. In your OnLookup you should add something like: IF Field1 <> '' THEN IF NOT Table2.GET(Field1) THEN CLEAR(Table2); IF FORM.RUNMODAL(...
My understanding is that when the Lookup form opens, it is not pointing to the record that you have in the Table2 variable. Can’t rememebr exactly, but I think if you want ot use FORM.RUNMODAL instead of MyFormVar.RUNMODAL, that you have to do a find on the rec, bt I may be wrong, but you may want to try it. Table2.GET(Field1); Table2.FIND('><='); ... (populates some other fields) Sorry, I have had this problem bofore, but can’t be 100% if this is how I solved it.
here is what you need to do. You need to set Table2 to point to the record you’ve selected. if Field1 <> ‘’ then begin Table2.setrange(code,Field1); if Table2.find(’-’) then; Table2.setrange(code); end; IF FORM.RUNMODAL(0,Table2) = ACTION::LookupOK THEN Field1 := Table2.Field1; VALIDATE(Field1); that should do the trick.
Why do you need to code the Lookup? It looks pretty standard, doesn’t the TableRelation take care of it by itself?
quote:
My understanding is that when the Lookup form opens, it is not pointing to the record that you have in the Table2 variable. Can’t rememebr exactly, but I think if you want ot use FORM.RUNMODAL instead of MyFormVar.RUNMODAL, that you have to do a find on the rec, bt I may be wrong, but you may want to try it.
This meaning this is is first and only time I used FORM.RUNMODAL instead of MyFormVar.RUNMODAL in a lookup trigger? [:P] Funny, but possible! I’ll check it later. [:)]
Originally posted by David Singleton - 2005 Oct 27 : 15:48:24
[/quote]
I tried… IF Field1 <> '' THEN Table2.GET(Field1); … and it worked! [:D] I’d swear I had tried it already, but… Oh, well! Thank you, David! and thank you, Ahmed, Thank you, Anfinnur. Your advise was helpfull as well. [:)] Anna
quote:
Why do you need to code the Lookup? It looks pretty standard, doesn’t the TableRelation take care of it by itself?
Originally posted by nelson - 2005 Oct 27 : 16:45:43
I need to VALIDATE the returned value. Anna
quote:
I tried… IF Field1 <> '' THEN Table2.GET(Field1);… and it worked! [:D]
Originally posted by Anna Perotti - 2005 Oct 27 : 17:47:16
Thast’s odd, because if Field1 = ‘’ then you should have got a run time error? I originally wrote IF Table2.GET(Field1) then table2.find('><='); But I assumed that since you didn’t get an error that you had sorted that out in earlier code. Anyway if it works thats great.
quote:
quote:
Why do you need to code the Lookup? It looks pretty standard, doesn’t the TableRelation take care of it by itself?
Originally posted by nelson - 2005 Oct 27 : 16:45:43
I need to VALIDATE the returned value. Anna
Originally posted by Anna Perotti - 2005 Oct 27 : 16:56:21
But it will always be validated. When the user tries to exit the field, the field will be validated. Sorry, I don’t understand… [:I]
quote:
But it will always be validated. When the user tries to exit the field, the field will be validated. Sorry, I don’t understand… [:I]
Originally posted by nelson - 2005 Oct 27 : 18:00:26
Mhmm… no, it’s me who am messing things up chasing after phantoms! [:I] I’m not sure about when and where I lost myself on that silly problem. The forms working on that table need to be restyled on the fly according to some properties found on the said Table2 - input fields must appear, desappear, editable or not… Cursor needs to jump to the right next field, without knowing which the next field is… I think I got entangled between field triggers, form triggers, control triggers… You took me out of the mud and washed my eyes, thanks! [:P] Anna
Heh, I knew there was something fishy… [:)] Actually, this subject is related to something which can possibly be considered a bug[Oops!] in Navision’s Lookup behaviour. I will paste a message I posted at another forum: http://www.mibuso.com/forum/viewtopic.php?t=8143
quote:
The behaviour of the OnLookup triggers for Tables was changed somewhere between versions 2.50 → 3.x I’m not sure which version changed it but it used to work the same at Table level and at Form level. Now it only works at Form level and damn me if I know why… The upshot is that before we could use the following code in OnLookup: Field - OnLookup some code, bla bla bla Field := 'Some Value';And this would run the field’s OnValidate trigger. Now we have to do it this way to get the same effect:Field - OnLookup some code, bla bla bla VALIDATE(Field,'Some Value');I really don’t like this behaviour as it causes the field value to be validated before the user even leaves the field. That’s not standard behaviour if you have no code OnLookup and the system uses the TableRelation to provide a lookup to the user. In this case, the user will be able to retrieve the value, see it being copied to the field but only validated when he tries to leave the field. On the other hand, if you change a Post Code in the Customer Card (which is a field where the lookup is provided through code), you will see that the system will fill in City and County as soon as you press OK on the Lookup form - so before exiting the field. I’m not sure why they changed it and I’m not even sure if the change was documented (this is of course my fault for not searching all the “Changes” docs). But anyway, I would call this a bug. Unless someone knows better.
Why is it that every time I mention this alleged bug, the topics just fade out and die?.. The same happened on the other forum’s thread…
Naah its always been like this hasn’t it? The online help is pretty clear, is says that any code in this trigger will replace the default action, and part of th edefault action is the validation of the field. In any case, it should work this way, since you often have a scenario where you want to do your own lookup specifically to avoid validation, if it automatically validated, then you couldn’t do that. Also I will often write code like… Field - OnLookup MyForm.RUNMODAL some code, bla bla bla VALIDATE(Field,'Some Value'); some more code .... you couldn’t do this if the validate was at the end.
quote:
Why is it that every time I mention this alleged bug, the topics just fade out and die?.. The same happened on the other forum’s thread…
Originally posted by nelson - 2005 Oct 28 : 21:30:54
Nelson, I don’t remember the change in behavior that you describe - I probably wasn’t coding OnLookup triggers back then and so it just passed me by. However, I agree with you that the OnLookup on the table is totally worthless because of the way you have to handle the validation. In my opinion the form OnLookup has the correct behavior where the value of the control is passed into and out of the trigger via the text variable with a Boolean result indicating whether of not a selection was made. It would be great if the table OnLookup trigger worked this way. As it is I have to write a lookup function on the table with the same parameter and result as the form OnLookup trigger and then call this function from each of the form controls where I want this lookup - a real pain to implement and maintain.
I can’t see any logic or reason that the OnLookUp on a table should be the same as that on a form. On a form you have a contol, and the control has a source expression. If the source expression is a field in the source table of the form, then when you enter a value in that control (by what ever means,) it calls the validation trigger in the field. That is logical, since code on a form should not have any structural effect on the code of the underlying object. If I place code in the OnLookUp trigger of a table, then (as defined in the manuals), that code will replace the default action of that field. In this case it will deactivate the Lookup form function and the Validate action. This code is in the same object, and it makes sense that it can act this way. (Keep in mind that there is no default action for on lookup in a control on a form. It can only inherit the action of the table). I think you are both confussing these two totaly different triggers just because they have the same name [:D]. But really I can’t see any logic that makes you think they should be the same. And definitely its a design feature, and one that needs to stay as it is. And I’m pretty sure I rememebr it working in ver 1.3 like this, but can’t remeber if it was in 1.1. AAre you sure it worked different in 2.50?
I’m not advocating that the OnLookup for table fields be the same as for form controls, only that they behave in the same manner. That is, that the contents of the control are passed to the trigger through the text variable and are passed back to the system through that same variable and that the execution of the validation logic is performed by the system (if indicated by the result of the lookup trigger) when the user exits the control. If I want to replace the default lookup behavior for a field in a table with a behavior that can only be obtained by the use of the OnLookup trigger for form controls then I have to code that trigger on every form where that field is used. For example, if I want to replace the default lookup behavior for a field so that the user may partially enter the value of the field and then press the lookup button to get a lookup list that is filtered by the partial entry then this cannot be done by coding a lookup trigger on the table. This is because the lookup trigger on the table has no knowledge of the partial entry made by the user. Whereas the lookup trigger on the form control knows what the user has partially entered because it is passed to the trigger through the text variable. Therefore, if I wish to achieve this type of lookup behavior for this field I must code the OnLookup trigger on the form control. And if I have several forms where I want to place this field, then I must code the OnLookup trigger for that control on each of the forms.
Maybe I am missunderstanding you rneed here, but I have implemented exactly what you are saying, and it works fine. Can you explain what it is that can’t be done?
quote:
Can you explain what it is that can’t be done?
Originally posted by David Singleton - 2005 Oct 31 : 04:51:59
At the simplest level I cannot create an OnLookup trigger for a field that causes the field validation to be performed only after the user exits the field.
That’s exactly my point. I am just now installing old 2.x versions to make sure I haven’t gone mad.
Ah that’s clear now. nelson, how was it exactly before?