Detect list selection
In a table view/list, select a row and the form slides out. One can move the selection up and down the list and the form data changes to reflect the selected row. Standard Ninox behaviour.
Is there any way to detect when a (different) row is selected? Basically a trigger when the row selection changes?
42 replies
-
That's it. The modules have to be loaded by a formula field in that table, or the onselected() function doesn't run, even though the JS calc still works.
When the modules are loaded by that initialisation routine all using a different table, onselected() doesn't run when used in other tables.
Your example shows it all working in that same table, so the problem did not arise.
-
Ok, your example works for me. So I considered the difference from my db.
I added an onselected() function (that does nothing of any use) in my initialisation table. Then onselected() DOES work in other tables.
So I removed that function from the initialisation table in your test db. It still worked.
I removed it from my db and it worked.
About the only consistency is that if I open that initialisation record automatically on load, onselected() then doesn't work in other tables.
If I don't run it on load and just open that table manually after the db is loaded, then onselected() works.
I need to look further at the differences between my db and your test one. Have to look into that tomorrow.
-
UKenGB Ok, let me know because, I'm interested in eliminating a bug in my Ninext code. Thanks in advance.
-
Jacques TUR I had to leave this for a while, but looking at it again it is consistent that if I show the Formula that loads the modules as part of 'Trigger after open', it doesn't work. If I show it later manually, then the routines that use your modules DO work.
I still have no idea what is different about this from your test db, but I have decided to use a different approach so I don't have to rely on your modules. Their functionality is great and should be incorporated into Ninox code, but right now I have no time to investigate further. I hope to look at it all again later though. If in the meantime you figure it out, do please let me know.
-
UKenGB I understand that it is too long for you to do all these tests. Can you just send me the code you had put in the 'Trigger after open' ?
-
Jacques TUR I am sorry about this as normally I can spend as long as I want on something like this, but for the next month I have an unusually large number of things to do, some of which involve the db in which I wanted to use your modules. So I'm not trying to brush you off, just haven't the time to do all that I want at the moment.
That said, the 'Trigger after open' just had this line:-
popupRecord(first(select StartUp))StartUp being the table just for this, with a single record and the formula field that loads the modules. I would see them load, then close the popup etc and check in the other table if it was working, but it would not detect the click on the list. If instead I remove the Trigger line above, re-open the db and then manually go to that same table and exactly the same, watch the modules load and then go to the table that used the module to detect the click, but now it works. Same exact process, but one initiated automatically by the 'Trigger after load' and the other manually.
-
UKenGB Everything you are doing seems to be correct. It's a problem that seems random, and just this morning I found a random module loading error in my code. Or more exactly, an error that depends on the speed of loading the modules. At the first loading everything goes well, then when the modules are in the browser cache, it doesn't work anymore.
I upgraded the version of exModule to 1.02 beta to fix this. Maybe now the loading works well on your app?
-
Jacques TUR I'll give it a try and let you know.
What happens if that formula field is displayed again, once the modules are already loaded? I thought they should simply load again every time the code is run from the formula field. However, it seems to instantly display the previous text from the modules loading, faster than it can possibly be actually loading the modules.
Should it reload each time or does it in some way check and not do so if already loaded?
-
UKenGB The code checks if the loading has already been done. If it has, it writes :
exModules version 1.02 beta already loaded
-
Jacques TUR Brilliant. I'll have to look into it again.
-
Jacques TUR I see that 'already loaded' statement even the first time - for each module in fact.
I just tried it all again, but same problem. If I load it via the 'Trigger after open', the onselected() function does not run. If I load it manually after db is open, the function runs. I have an alert in there so I can tell 100% if it runs or not.
BTW, I'm running on MacOS. Is this a platform issue?
-
UKenGB
With your indications, I could reproduce the problem and find the bug. Indeed, the hooking procedure that sends the onselect event was not set up.
I corrected it and now it should work in all cases:
exViewEvent version 1.08 beta loadedThanks for your help and patience
. -
Jacques TUR I'll have a go Jacques and let you know.
-
-
I've not tried it loading on open, but just loading them manually is causing a problem. I have a formula field which is not updating when switching records. So if I go to table, click record in list and the formula shows correct. Select a different record (previous next etc) and the formula field is not always correct. Sometimes blank and sometimes shows the value from the previous record. If I show that formula field in the table/list view, that column (and any others based on it) simply go blank.
I exited the db and loaded again, without loading your modules and this problem does not occur. So your modules is causing this.
It's as if the onSelected() function is filtering out some of the events that Ninox normally sees and uses to update stuff when the selected record changes.
The formula field is using a child table in the calculation. If I remove the formula field all looks ok, so this may have always been an issue with the modules and only now apparent due to the introduction of the formula.
Anyway, definitely works perfectly if modules not loaded.
-
Well it's a bit weird, but the good news is that the latest version of your modules seem to load perfectly using 'Trigger on open' and onselected() is doing what it should. So well done Jacques and thank you.
What is weird is that the formula field was getting screwed by the code run in onselected(). There are 2 parts to that, both of which set some 'memory' fields. One is global and the other is per record. They are used in child tables in order to access values not normally accessible to them. The code works and all is good, BUT…
The formula field causing the trouble does some array manipulation based on the children of this main table, not actually connected to the memory fields previously mentioned. Again, that formula field works fine, as it should, until the code that sets either of the memory fields is run and then the formula field displayed in the main list/table view blanks out, on one or more rows, although the formula field usually still looks correct on the form if open. So a complete discrepancy between the same (formula) field shown on the form and in the list.
Redrawing the main list puts things right and the formula field again shows correctly - until the memory field code is run again. And so on.
So I eliminated the formula field by instead setting a Text field when the child table is updated. Needless to say, that field is not affected by any code being otherwise run.
I can only assume it is a Ninox bug where it is not correctly updating all it should and when it should. Fortunately, in the end I found a way around it and with Jacques' module working well, everything is working as Ninox should, but currently doesn't due to an obscure bug and a lack of user control of the interface events, both of which should really be addressed by Ninox.
Content aside
- 1 yr agoLast active
- 42Replies
- 586Views
-
3
Following