August 19, 2014 at 1:19 am #783
This has been asked few times but I dont seem to able to find the answer from previous posts.
I have a browse control on an access control and they have a master-detail relationship which is working fine. I would like to display one field value from current selected browse row on the access control.
Following some of the previous discussions, I tried to create a Rule_ with .browse_data to return the value. But .browse_data is an object which is a list of records in the browse, how could I access the current selected row from there? Is there any other way of doing this?
Thanks a lot.August 20, 2014 at 2:36 pm #1080
ok, adding the method List_Selection(selection) into controller seems to do the trick. Whenever a row is clicked on the browse control, this method will be triggered automatically. The selection parameter is passed in as a single element object that points to the index of current row that is clicked, e.g: #(0),#(1)..
But in this case, i avoided using row index to access browse row. Instead,
1) I created a reference to the browse control and another reference to the browse field control by using .FindControl method.
2) I also created a separate Field_ definition to handle heading and format stuff.
3) After that I put following code under List_Selection(selection) method,
if (selection isnt false)
.browse = .FindControl('browse_name') //a reference to the browse control
.newfield = .FindControl('newfield_name') //a reference to the new field i would like to show on access
.newfield.Set(.browse.GetField('browsefield_name')) //using .browse.GetField and control .Set to assign value
I think it will be a good practice to have all those essential methods added into controller for both access and browse, regardless if we are going to use it. That could save a lot of time to figure out what is what and what does it do.August 20, 2014 at 8:48 pm #1081amckinlayKeymaster
Glad you figured it out.
I am not sure what you mean by “methods added into controller for both access and browse”?August 21, 2014 at 2:07 am #1082
It is just my idea and may not be necessary for others. Here it is,
When defining an Access/Browse control inside of a controller, normally the developers would need triggers such as
On_Insert, On_Delete, On_Modify on the record level to interact with user actions to perform data validation and other type of business logic. Furthermore, the developers would also need triggers such as On_Validate on a field level to interact with users to do similar tasks.
Mostly of the similar triggers are already provided in suneido controls, but require additional actions to be added into controller. Sometimes, it takes a lot of time and effort to figure out how they should be defined or if they exist at all. So my idea is that, it would be a good practice to add them into the controller as a standard step when defining controller.
When I look at them later, I can see immediately what triggers are available and use them accordingly. It is also easier for other developers to do continuous support and modification.
- You must be logged in to reply to this topic.