How? Reset 2nd lookup on change of 1st lookup?

[onoehring]

Hi,

I am sorry to bother you with this, but I could not find the solution searching the forum.
When I have 2 lookups (A and B) and B is "Filtered by A" (AG setting with lookupfields) ... how can I make field B show something/nothing when field A is being changed?

Thank you
Olaf

[onoehring]

Hi,

just asking myself: is this a bug?
I would really assume, that once I change the master lookup field, the child lookup should be reset to nothing (or default).
Am I wrong?

Olaf

[jsetzer]

Hi Olaf,
this should be the default behaviour.
Any errors in console?
Jan

[onoehring]

Hi Jan,

well unfortunately not.
I am using AG 5.82 and this is not the only field in the only table where this occurs.

No, no JS errors in Console

Web (vivaldi, chromium based)

ec20200316_01_dependent_lookup.gif (100.67 KiB) Viewed 5754 times

AG

ec20200316_01_dependent_lookup_AG.png (49.02 KiB) Viewed 5754 times

Olaf

[jsetzer]

Sorry, no clue. I never had problems like this.

[onoehring]

Hi,

thank you Jan.
I regenerated the application and did not use any custom code for testing (completely new folder, nothing in hooks - or else - changed)
My setting is
field_A1 which is a master and field_A2 which is dependent on field_A1.
In the same table I also have field_B1 (master) and it's dependent field_B2.

Neither one works. When I change A1 the field A2 is not reset, when I change B1 then B2 does not reset.

I also tried this: remove field A1 and A2 (so only B1 and B2 stay in the application) and remove field B1 and B2 (so only A1 and A2 stay in the application) because I thought they might interfere. Nothing: After regeneration of the code in new folders, also no changes to the child fields (_2)

Note: I am working as superadmin

I am kind of lost and would be very happy, if someone (besides Jan) could tell me that it works for them of could also tell me that it does not work as in my case. Even better: Suggest a reason why ... and ... a possible solution.

Olaf

[pbottcher]

Hi Olaf,

can you confirm that it is working if you create a new record?

I have seen this if creating a new record, the dependent lookup is reloaded and set to "no match found".
For an existing record the dependent lookup is not reset.

[jsetzer]

I'm still not sure if I understood what you want to achieve. Is this your requirement?

ZpKtLGWIVw.gif (117.72 KiB) Viewed 5691 times

PS: I have attached a hello world axp

[jsetzer]

@Olaf: Just an idea which came into my mind a second ago.

I know you are doing a lot advanced customization on lookup-sources using custom sql and even custom views. So It could help if you would monitor the network traffic and watch out for errors in your customized queries.

Open developer tools (F12 in chrome)

1. Open Network tab
2. filter for ajax_combo.php
3. Open your sub-lookup

chrome_RWKbJQOnmG.png (36.81 KiB) Viewed 5690 times

Whenever you open a lookup, there will be a request and (hopefully) status=200 response which you can select and analyse in detail. You will see the request-parameters AND the responded JSON.

• Check the AJAX requests (from browser to server)
  I guess there will not be any problem because those requests and parameters have been generated by AppGini
• Check the JSON responses (from server to brower)
  I you are using customized advanced queries for your lookups, the server will use your SQL for fetching records and returning them as JSON result to the browser. This could lead to problems or non-parsable JSON results. There may be important information or even errors which could stop resetting and re-populating the dropdown lists.

In your screenshot I have seen that you are using strike-through formatting in your dropdowns. Maybe there is some non-escaped or wrongly escaped HTML code being returned from your advanced query. Sometimes it is only such a small bug which leads to a broken (misconformed) JSON.

It is just an idea for narrowing down the problem.

Best,
Jan

[pbottcher]

Hi Olaf,

I think we had this issue already.

Have a look at
viewtopic.php?t=2955

It seems to be a caching issue.

[onoehring]

Hi Jan & pbötcher,

at this moment I want to quote Jan (from pbötcher's link above):

@pböttcher
You are my personal SuperHero #1!
Thank you for taking the time and precisely pointing me into the right direction.

With my own words: Thank you very much pbötcher - your suggestion was indeed the solution.

Of course many, many thanks to Jan as well to taking the time to create a demo and attaching it. I generated a new app with that and for me it actually did not work. So I took a look at pbötchers post ( viewtopic.php?t=2955 ) and adjusted the file in Jan's demo - works like a charm.
Your addition to simply renaming the caching file in the /hooks/tablename_init is marvelous.
Thank you also for teaching me a little more "browser console". Much appreciated.

For others: If you disable cache like pbötcher suggested, it was the child-fieldname (for me), that needed the commented lines.


All blessings done, I must confess, a new problem arises:
This fails:
I used Jans suggestion to rename the hooks/tablename-ajax-cache.php file (in hooks/tablename _init function) so no caching for this table. This results in correct behavior of all fields except my ID_location. To request values for ID_location have created a view on the server (instead of 5 KB SQL). In AG I have only this for the ID_Location lookup

Code: Select all

SELECT * FROM view_freieplaetze_oben AS ecomo_location ORDER BY Lagerort_Kurz, Bereich, ID_posX, ID_posY, id_posZ DESC 

So, any idea, why the field shows "no records" and this request suddenly returns "no records" when opening the lookup even though a) the record has a value set (can be seen in table view) b) the sql shows results in phpmyadmin.

Do you have any idea, why this lookup fails now?

This works:
when I use pbötchers suggestion only and comment the lines in /template/tablename-ajax-cache.php for the child lookup A and child lookup B everything is fine: ID_location works as smooth as ever and when I change master lookup A it's child is updated, same for master lookup B: A change here updates child-lookup B.

Do you think this is a bug which should be posted in the bugs section?

Olaf