Are there Trigger limitations?
I have a DCF (DMCF?) where a "Trigger after update" has the code:
'V.Välj Region' := "";
'V.Välj Distrikt' := "";
'V.Land' := text('V.Välj Land')
it does't work BUT if I have the code:
'V.Välj Region' := "";
'V.Välj Distrikt' := "";
'V.Land' := 'V.Välj Land'
the trigger will work, but then I get the number that is in the 'V.Välj Land' and not the text representation.
What is wrong in this? Is there limitation what kind of code I can have in a Trigger?
Appreciate all help I can get! (If there is text in a manual to describe what I do wrong / how it work - please point me - I have not been able to find it.)
/Niclas
7 replies
-
Is Välj Land a choice, multi choice or dynamic version of the two?
what you are seeing is just the numerical code assigned to the choice.
-
What you are seeing has nothing to do with the use of triggers, but is just the result of how Ninox treats type casting. You would have exactly the same result in a script attached to a button.
In Ninox, as in other IT systems, each object has a type. A number field has the type "number", a text field has the type "string", and a dynamic choice field has the type "dchoice", which neither a number nor a string. You can observe this yourself by using the "debugValueInfo()" function.
Now, given its "No code" motto, Ninox tries to hide those nasty CS realities by performing some amount of automatic type coercion: most of the time, when you assign a value of one type in a context where another type is expected, Ninox does silently perform the conversion for you (but sometimes it just complains that the type submitted is incorred). This automatic conversion does give the expected result, or not, depending on… what you expect.
In this case, if you assign the content of a "dchoice" object to field of type "number", Ninox will automatically coerce the the"dchoice" into a number and assign the numeric value of the identifier of the chosen record in the source table. If you assign the content of a "dchoice" object to field of type "string", you would expect Ninox to assign the string shown in the DC field itself, as set by the "Dynamic value name" option of the field. Not so… Ninox first coerces the "dchoice" into a number, as explained above, and then coerces this number into a string. Don’t ask me why it does it that way, but that’s the way it is.
If you want to put the value of the string shown in the DC field itself into a "string" object, you must specify an explicit type conversion by using the text() function. That’s what you did in your first example, and it is the right thing to do.
For more background information, see "Type conversion" on Wikipedia.
-
Alain, thanks for taking your time to answer. I'm bit familiar with typecasting but have never liked it :- ).
I worked a year or two with smalltalk 30 years ago and then everything moved to java (1995-97ish) and as I remember we had to think of typecasting in Java but almost never did that in smalltalk (but we had other challenges).
In this case I may struggle with the "low code" environment as I like a msg that tells me what goes wrong.
Anyhow - I don't understand as in my fist example where I did the typecasting with text(....) it doesn't worked even though I put the result in a text field.
So guess I misunderstand as you said it was the right thing.
What I try to do (and I saw you responded to my months old entry) is to "translate" what I select in my Choice field and then store that text in the database. As diskspace is "no cost" this day I can't understand why I should store codes instead of the text. In my opinion, the Choice field should have an option if you wat the text or the number as the result.
-
Sorry, I did not interpret the "it does't work" as you intended. And, believing thar it did indeed work in the first case (as IMO it should), I did not perform my own test. Now I have build a small test database and, indeed, if the espression "text('V.Välj Land')" appears anywhere in the "Trigger after update" script, the script is not executed at all. I would submit the case to Ninox support.
I can propose a workaround:
'V.Land' := record(a,number('V.Välj Land')).bWhere:
"a" is the name of the table feeding the dynamic choice field, and
"b" is the name of the field containing the text to be copied from that file.
-
Alain, thanks again. I thought I may have expressed my self a little bit cryptic so you had miss-understood but I had no time to reply. Glad you confirmed it should have worked (it gives me some confidence!). I have started to try what you have suggested and I may be able to work with that but I still hope the"Trigger" can work. Hopfully I get some times this weekend to try it more.
-
Alain Fontaine Short update. I changed 'V.Land' :=text('V.Välj Land') to your suggested 'V.Land' := record(Geografi,number('V.Välj Land')).'G.Land' and it worked fine.
I still think the text(...) should work and it bugs me as I think it has! Anyhow I have solved my problem for now.
If other read this - I run native Mac and the database on iCloud so it is replicated to my iDevices.
I'm a little bit suspicious this error "showed up" when I move my database from a local disk to iCloud but if there is limitations what you can do when on iCloud I expect it to be documented.
-
I did verify that it does not work on the iPad version, with a local database. So it does not seem to be an iCloud problem.
Content aside
- Status Answered
-
1
Likes
- 2 yrs agoLast active
- 7Replies
- 165Views
-
3
Following