Hi
Two days ago we installed 3.1.5. Since then I get an error (null pointer exception) when I set the text of a text field (without data provider attached) with:
elements.x.selectAll();
elements.x.replaceSelectedText("something");
I found a thread in the forum from 2005 where someone noticed the same error. Since I never had this problem before 3.1.5 I’m asking: Why does it occurr now? Was it changed once before and rechanged? On purpose or by accident?
I now attached a data provider (dummy calculation) and it works. But I hope this is only a temporary work around and will be changed in a futire release again. I’d like to use fields without data provider in the future.
Thanks and regards
Birgit Rieder
Its indeed an issue (will be corrected in next release), but why whould you want to use a field without a dataprovider?, better to use a global dataprovider than selecting the text from UI
Hello Jan Blok
I’m glad to hear that this will be corrected in the next release. We really need this feature and are looking forward to the fix.
Where do we need this? In some fields we display information to the user which is not stored in the database. And this information is to complex for a calculation and is dependent on the form and the selected entry. E.g. in one field we display a postal address of a pupil. This address is dependent on the majority state of the pupil, its parents (sharing one address or not) and a possible guardian. To construct the correct address we execute some queries on the database. Another field is sort of an extended status line. It displays additional information for the selected entry. The field may be filled by all kinds of forms from all over the application.
Of course we could use global dataproviders. But I try to avoid all kinds of globals. Even in your documentation you mention to minimize the use of globals.
So, I just wish to have an entry field, where I can set the text. (Even selecting the whole text and then setting selected text is a workaround).
Thank you and kind regards
Birgit Rieder
birgit:
Even in your documentation you mention to minimize the
Not sure to where you did find this in the docs…but “minimize” to the extend of crippling the solution is for sure not intention.
Jan Blok
The chapter “best coding practices” on p. 150 in the servoy developer reference guide says: “…limit the number of global methods…”
Without reading this, I know from my own (bad) experience that globals (methods and variables) should be avoided if possible. I agree, of course, that crippling the application is not the intent. But as you probably also know, sometimes you have to weigh the advantages and disadvantages. In my case a global variable versus setting selected string. As long as accessing the selected string of a text field was possible I did choose this. Probably since I know it from earlier programming languages I used.
Kind regards
Birgit Rieder
Hi Birgit,
Not sure if it will solve your problem, but have you tried ‘virtual’ table columns?
Define a calc returning nothing
return ;
This creates a column which is not saved in the backend database, you may be able to use these in place of a globals.
I have a table of screens, I have a number of columns I use to create the user interface. Before Marcel taught us about ‘virtual’ table columns, I had to define about 8 globals per screen…
I would find it quite helpful to be able to access a text object per Brigit’s post. The calculated “virtual” column is good in that it has a set data type during definition.
However, even a conventional Servoy text object bound to a data provider column sometimes still lives in the world of “text” (I found this out the hard way with my unpopulated or null text fields entering a calculation during record adds … and then attempting to write a text string to a numeric field in Postgres).
To have a “Text” Field object (text by default I assume) that:
a) inherits the data provider data type (at least for provisioning to the data provider) IF bound to a data provider
b) is able to be inspected and set per Birgit’s thread
c) can act as a data type specific field (e.g. - Numeric or Date type) so as to avoid sending incorrect data types “down the pipe” (ie - to the db via the data provider)
… would be helpful. Variables and unbound text objects then become more localized to the Form itself and its methods (I too tend to lose track of globals after a while if I get too many Globals acting as “form level variables”).
I think Birgit’s idea is correct here and worth reflecting on …
M^2