L
Lieven De Foor
Guest
Hi Evan, In our case it would suffice to have this capability once a class in instantiated, but I can see benefits/posibilities before instantiation as well... The actual use case in which we need this is as follows: We have a dialog showing some fields: Eg. User query dialog: - User type (combo box with options 'Batch' and 'Interactive') - Active (combo box with options 'Yes', 'No' and '?' (all users)) We have a simple data object with the following properties: - UserType (Enum, options UserType:Interactive and UserType:Batch) Initial value can't be set through INITIAL for class/enum types so this might be a problem already. We set the initial value in the constructor. - Active (Logical, INITIAL TRUE) We can pass the data object to the UI, which will call a routine to populate the fields in the UI with the values from the data object using reflection (the names of the fields correspond to the name of the object's properties). The user can change the values in the UI and press Apply which updates the value in the data object and publishes an event which can then be caught by other UI to e.g. reopen a query using these settings. -> There is also a Reset button which should repopulate the values on screen with the original (initial) values of the data object. -> In order to do that now we need to store the initial values somewhere, either in extra properties (UserTypeInitial, ActiveInitial), a temp-table or some other means... -> It would be useful if we could get the property's initial value using reflection instead of having to keep it in a separate variable/temp-table. Since you can't specify the INITIAL attribute on class based variables/properties, adding that functionality to class based properties/variables might be a pre-requisite (or it must be define what we mean by 'initial value' in those cases). Hope this makes it somewhat clearer...
Continue reading...
Continue reading...