locked
What override method is called when the "Show Add-new Row" button is clicked? RRS feed

  • Question

  • What override method is called when the "Show Add-new Row" button is clicked?

    FYI: Neither the AddNew_Execute() or AddAndEditNew_Execute() methods are called.  



    Wednesday, April 20, 2011 7:52 PM

Answers

  • Hi Garth,

    Some sort of "collection changed" event on the collection itself?

    The collection probably implements something like INotifyCollectionChanged.

    Yann

    Thursday, April 21, 2011 12:27 AM
  • Hi Garth,

    "How do we manage the changes to the Grid columns?"

    I use INotifyPropertyChanged on the Collection.SelectedItem, removing any existing handler when the SelectedItem changes, adding my handler.

    		private void Collection_SelectionChanged()
    		{
    			var selectedItem = this.Adjustments.SelectedItem;
    			if (selectedItem == null)
    			{
    				return;
    			}
    
    			Dispatchers.Main.BeginInvoke(() => {
    					((INotifyPropertyChanged)selectedItem).PropertyChanged -= GridPropertyChanged;
    				});
    
    			Dispatchers.Main.BeginInvoke(() => {
    					((INotifyPropertyChanged)selectedItem).PropertyChanged += GridPropertyChanged;
    				});
    		}
    
    		private void GridPropertyChanged(object sender, PropertyChangedEventArgs e)
    		{
    			switch (e.PropertyName)
    			{
    				case "SomePropertyName":
    					//do something here
    					break;
    			}
    		}
    

    "is it correct to say that some of the IContentItemProxy control interface implementations in B2 are incomplete?"

    I don't know if I'd say that the implentations are "incomplete", but it's pretty hard work at times, working with so many "unknowns".

    So, yes, some LS-specific documentation would indeed be helpful. In the meantime, we have to struggle along, & find our answers through "hit & miss" & collaborative efforts.

    Yann

    Tuesday, April 26, 2011 11:51 PM
  • I still think you are misunderstanding what I have said.

    I never made mention of the SelectionChanged event of a collection; I only made mention of the Changed event. Both of these events are on all visual collections, but have different behaviors and uses. The former (SelectedChanged) notifies the programmer when the selected item of the collection has changed. The latter (Changed) notifies the programmer when the number of items of the collection has changed, their position, and when the collection has been repopulated.

    The solution to use the Changed event (not the SelectionChanged event) is not a workaround, is not design cut-off, and is the intended LightSwitch design in this case. From this event handler, you can consistently detect when a new entity has been added to the collection by the AddNew commad, AddAndEditNew coomand, the placeholder row in the Data Grid, or even when you call AddNew or AddNewAndEdit on the collection from code.

    There was no mention of any change in this functionality from Beta 2 to RTM, so I don't know why you are bringing that up. Please read Beth Massi's sticky in this forum for the notable, post Beta 2 bug fixes.


    Saturday, April 23, 2011 9:19 PM

All replies

  • Hey Garth,

    What are you looking to do?


    Derek
    Wednesday, April 20, 2011 7:57 PM
  • Hey Derek,

    Thanks for your interest.

    Pretty much everything that is done within the AddNew_Execute() or AddAndEditNew_Execute() levels must also be done when a new Row is added by having the user double click on the row with the "Show Add-new Row".

    A specific example is regarding Many 2 Many Entities that require PreprocessQuery sorting.

    It is not acceptable to the user (business process requirements) to have Grids sort in PK index order for the FKs in the Many 2 Many tables. Often, as is the case here, Many 2 Many tables will only contain a Primary Key and 2 FK values.   The Summary values display on the Grid so the Grid should order the list according to the Summary values.  Standard app 101 stuff, eh?

    The Screen Query will only allow a sort on Properties with scalar values (columns in the table - not columns in FK related tables).  Therefore, Entity Queries must be used with PreproccessQuery code.

    Therefore the use of the Screen "+ Add <Related Collection Entity>" feature doesn't work because the "Query Source" property is missing for a Collection that has been added to the Screen with "+ Add" feature.  To be clear, an Entity Query cannot be used with the "+ Add" feature.

    When a Collection for a grid is NOT added to the Screen with the "+ Add" feature.  The Screen will not write the Master PK value to the corresponding FK in the Detail Grid Many 2 Many table.

    Therefore, it is necessary to do this in code.

    In the following example the LSMUsersSQ is the Master Collection and LSMUserPropertiesSortByPropertySQ is the Many 2 Many Detail Grid.

        partial void LSMUserPropertiesSortbyPropertySQAddNew_Execute()
        {
    
          LSMUserProperty lup = LSMUserPropertiesSortbyPropertySQ.AddNew();
          lup.LSMUser = LSMUsersSQ.SelectedItem;
    
        }

    Hey Derek, I've been meaning to ask you if you are running B2 apps in production with users yet.  

    I'm trying to find a few other developers that are also running B2 apps in production to share experiences.  My email is garthh@vanguardok.com  It would be encouraging to report a recap to the community.  Our community goal is to have as many companies as possible running LS apps with B2.  Doing this assures the we'll have the best possible RTM.

    Wednesday, April 20, 2011 9:31 PM
  • FYI:  If any of the LS Team wants to have screen shots of this scenario, I've already submitted them to Beth.   I cannot share the screenshots with the community as it is proprietary to Vanguard.
    Wednesday, April 20, 2011 9:34 PM
  • Have you tried using computed fields in your join tables to display in the grid as a scalar value?  Those are sortable and I have not had any real performance issues with mine.

    BTW Yes I am using B2 in production here with Windows Auth for about 15 or so users.  App is broken up into about 7 menu groups of about 5-8 screens each.  Utilizes 3 different databases including a WCF service back to an IBM DB2 database.  Reporting Services it is actually getting bigger all the time :).  I'll email you.


    Derek
    Wednesday, April 20, 2011 9:43 PM
  • Thanks, Derek.

    Wonderful news on the B2 production app!  I wish everyone would know this as well as the success stories of others with LS production apps. 

    Yeah, I'm one of those guys that likes to watch the daily news to see all the good stuff that "also" happened today.

    Please email me and I'll send you some clarifying screen shots. 

    Wednesday, April 20, 2011 10:29 PM
  • Will do.
    Derek
    Wednesday, April 20, 2011 10:35 PM
  • Hi Garth,

    Some sort of "collection changed" event on the collection itself?

    The collection probably implements something like INotifyCollectionChanged.

    Yann

    Thursday, April 21, 2011 12:27 AM
  • Please, I would like to know from the LS Team if we will be able to select a Query Choice for the "+ Add <CollectionName>" feature. This is the best possible solution and may simply be an oversight with B2.

    Queries need to be selected with "+ Add <CollectionName>".

    I would also like to know if there is (or will be) an event that is fired when the LS "Add new-Row" occurs.

    Working through a common combination of events for LS best practices and development methodology is necessary. 

    Thursday, April 21, 2011 7:05 PM
  • @Yann:

    Thanks for the suggestion.

    The <CollectionName>_SelectionChanged() event seems to be fired after the "Add new-Row" occurs.

    It should be noted that the <CollectionName>.SelectedItem is sometimes null with the _SelectionChanged() event is fired.  Extra code is required to test for this.

    There may be other conditions and/or issues.   I'm testing this now.  I am running into related problems that I'm trying to track down as the Many 2 Many has both "sides" of the Collection Query on the Screen in different Grids. 

    We need to know exactly what the conditions are that fire our LS API events.   We know that the API documentation is in the works. 

    Without the knowledge of event firing, an intense amount of system testing will be required to "guess" at what the firing is.  It is also possible that some of the event firing related to this may change with RTM.

    Many events are dependent on other events. 

    One of the incredible benefits of LS is the ingeniously simply structure of integrated events at the Model, View Modal, and View levels.  Making RAD biz app programming "simple" requires a lot of thought.

    The simplicity will, logically, require a methodology and best practices for LS - but this is good for RAD biz app development.  The LS Extensibility is designed to allow developers to integrate more complex functionality including the use of Custom Controls that go beyond the constraints of out-of-the-box LS.

    Yann, I'm waiting to get answers from the LS Team.  I'm also looking forward to understand how to apply Derek's suggestion.   After I hear back from the LS Team, I'll mark their answer and yours as answers.  Derek's solution may also be an answer.  To be clear, I don't want to mark an answer until the LS Team has responded so that they know I'm still waiting for an answer from them.  Makes sense, yes?

     

    Thursday, April 21, 2011 8:29 PM
  • Yes, absoltely. No problem..
    Friday, April 22, 2011 6:35 AM
  • I think you misunderstand what AddNew_Execute and AddAndEditNew_Execute actually are. They are not events (or event handlers). AddNew_Execute and AddAndEditNew_Execute are the Execute methods of the AddNew and AddAndEditNew screen methods. They only get invoked two ways: 1) you call them yourself in code, or 2) when a command that is bound to that method is executed (e.g. user clicks + button on data grid or list controls).

    What you are asking for is the Changed event for a collection. If you select your collection in the screen members list (let's say its the Customers collection), drop down the Write Code button, and select Customers_Changed. This will create a stub in the screen code for you to react to collection changes (reset, add, remove, replace).

    Friday, April 22, 2011 11:17 PM
  • Thanks, Justin.  I apologize for not using the correct terms.  Please allow me better explain the question.

    When an AddNew button is put on a Grid without an Override Method, clicking the AddNew button creates a new Row just like clicking on the "Show Add-new Row" button that is on the bottom row of the Grid.  In other works they both accomplish the same task of Adding a New Row.

    When an override Method is specified, the expected behavior is that when the user clicks either the 1) AddNew or 2) "Show Add-new Row" that the AddNew override method is called. 

    Either that, or that there is a separate override available for the "Show Add-new Row" button.

    If the answer is still "No", could you please explain why?

     

     

     

    Saturday, April 23, 2011 2:28 AM
  • The default behavior of the AddNew command is to invoke the AddNew method on the collection that it belongs to. The same is for the AddAndEditNew command, where it invokes the AddAndEditNew method on the collection. If you override these commands and do not fill out their Execute methods, then will do absolutely nothing. The AddNew and AddAndEditNew DO NOT handle adding to their collections, they invoke adding to their collections (unless you otherwise override their behavior).

    The placeholder row in the Data Grid works with a similar behavior as the default AddNew command implementation, except that it also places that new row into edit mode.

    If you want to do something special whenever something happens to add a new entity to a collection, you would write code in the collection's Changed event handler and ensure that the Action property of the event args is Add.

    Saturday, April 23, 2011 8:14 AM
  • To have a consistent GUI interface, the AddNew and the "Show Add-new Row" buttons should provide the user with the same experience.  One is a button at the top of the Grid (generally - it could be put anywhere on a screen) and the other is a phantom row at the bottom of the Grid that can be clicked.

    When a new row is created on the Screen, there needs to be an method that allows the programmer to take action when required.  The _SelectionChanged event can be jerry-rigged to accomplish this.  However a clean method would be to have a separate method to override.

    Likewise, there needs to be a CanExecute method.  

    I do understand that the 2 AddNew Row buttons and the Add/Edit buttons are different in nature.

    There are 2 issues here:

    1) The optimal consistent user interface implementation.

    2) What B2 and RTM will actually do.

    As expected, there will be many work arounds for application developers with RTM.  We just need to address them within our application code.  This is part of the purpose of having an application development methodology for LS (or any platform).

    Everyone understands that a design cutoff was made with B2.  What we don't really know is what B2 is.  Therefore, we ask questions as we run into development issues.

    I ran into a development issue when I tried to have the "Show Add-new Row" button function as the AddNew button.   I would like to have our LS applications be consistent with every editable grid having both "Show Add-new Row" and AddNew buttons.

    Is there a way to disable the "Show Add-new Row" button programatically within Screen Event (Method) Code?  There seems to be many conditions with B2 under which some interface properties are able to be changed. 

    Please consider that we do need to know what is being changed between B2 and RTM.  It is a matter of business.  Programming takes time and time is cost.  The smarter we work to get it right the first time, the more profit we make.

    I truly appreciate your support on this Justin.  I hope that my efforts to communicate better have been effective. 

    Saturday, April 23, 2011 5:11 PM
  • I still think you are misunderstanding what I have said.

    I never made mention of the SelectionChanged event of a collection; I only made mention of the Changed event. Both of these events are on all visual collections, but have different behaviors and uses. The former (SelectedChanged) notifies the programmer when the selected item of the collection has changed. The latter (Changed) notifies the programmer when the number of items of the collection has changed, their position, and when the collection has been repopulated.

    The solution to use the Changed event (not the SelectionChanged event) is not a workaround, is not design cut-off, and is the intended LightSwitch design in this case. From this event handler, you can consistently detect when a new entity has been added to the collection by the AddNew commad, AddAndEditNew coomand, the placeholder row in the Data Grid, or even when you call AddNew or AddNewAndEdit on the collection from code.

    There was no mention of any change in this functionality from Beta 2 to RTM, so I don't know why you are bringing that up. Please read Beth Massi's sticky in this forum for the notable, post Beta 2 bug fixes.


    Saturday, April 23, 2011 9:19 PM
  • @Justin:

    Please keep in mind the goal of this post is to provide the user with a consistent experience for the AddNew and the "Show Add-new Row" buttons.

    You are correct, I am still not clear (enough) about what causes the Collection Changed event to fire.  Therefore, I am unable to understand how best utilize the Collection Changed event.

          RE: The latter (Changed) notifies the programmer when the number of items of the collection has changed, their position, and when the collection has been repopulated.

    Please, is there more documentation available on the Collection Changed event?

    For example, how can the Changed event be used to manage the functionality for the the "Show Add-new Row" button create a method that reacts similarly to an AddNew CanExecute() method?   How can the Changed event be used to effectively turn on/off the "Show Add-new Row" button?  

    IMHO, the Notable Bug Fixes need to have more content and details.  However, it is very good beginning.  A majority of the current notable issues are related to Screen Collections.  Whether a bug is notable is dependent on whether a developer has had their B2 development impacted by the bug.  Developers going deeper with B2 production development will consider more bugs as being notable than curious folks playing around with blog examples.   A bug may impact the behavior of several other related functions that the developer fixing the bug may not be aware of.  Therefore, it is possible that the impact of a particular bug may not be known and/or reported.

    Have there been any bug reports that may impact how the current Collection Changed event will work with RTM versus the current B2 release?

     

    Monday, April 25, 2011 7:38 PM
  • Just a note that I marked your last reply as the answer regardless of whether there is more documentation on the Changed event.

    Your clear answer is to use the Changed event.  Thx.

    Monday, April 25, 2011 9:43 PM
  • There is no documentation around the Changed event for visual collections that I can find. But do take a look at the documentation of NotifyCollectionChangedEventArgs on MSDN for a better understanding of the types of changes the collection will notify. This is basically what happened for each enum constant of the Action property of the event arguments:

    • Add - An entity was added to the collection
    • Remove - An entity was removed from the collection
    • Reset - The collection was loaded, reloaded, or paged.

    As for specifying a "CanExecute" type of method for when a user double-clicks on the placeholder row in the data grid, there is no such notion. The placeholder row is a specific implementation of the data grid control that acts directly upon the collection it is bound. What determines if the row shows is 1) if you specify "Show Add-new Row" in the property sheet to be true, 2) if the collection is not read-only, and 3) if the user has permission to insert on the entity set (this is determined by the CanInsert method of the entity set).

    If you need to have more control over if a user can insert a new row into a data grid based on some other imformation that is not one of the three items above, you should then disable the placeholder row and force the user to add a row using a screen method (e.g. the + button) instead.

    Tuesday, April 26, 2011 1:24 AM
  • @Justin.  Thanks very much. 

    I wanted to know if there was something in the LS placeholder row implementation and/or AddNew functionality that might be useful at our app level API to make the two AddNew clickable "buttons" match functionality.  

    It is best to understand and maximize the power of what LS does before resorting to "app level" solutions to achive functionality. 

    This is just the beginning of the great new "invention" of LS.  There is truely some awesome RAD power in the LS architecture that I expect will be soon applied to other platforms.  Likewise, I figure that we'll see some great GUI features added into our LS toolbox without much hassle.

    Tuesday, April 26, 2011 4:04 AM
  • Hi Garth,

    These links may be helpful for you to understand what happening in the Collection_Changed event. They're mainly ObservableCollection(Of T), but the behavior should be similar, if a VisualCollection isn't in fact actually based on an ObservableCollection (which it could well be).

    I hope these articles might give you some food for thought, if not actual solutions.

    Yann

    Tuesday, April 26, 2011 4:35 AM
  • Garth,

    Justin's link give you a good idea of what's involved in the CollectionChanged event, here's a "definition" of the event itself (bold added by me).

    "INotifyCollectionChanged.CollectionChanged Event

    The event data of this event (NotifyCollectionChangedEventArgs) reports information about the nature of the collection change.

    This interface does not report changes to the individual properties of any objects that are contained in the collection, only that changes have occurred at the collection level. To report changes to properties using data binding at the object level, use INotifyPropertyChanged"

    Maybe these links will help too?

    http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7b14a18f-2ed6-4713-b747-9defd05978dd/

    http://japikse.blogspot.com/2009/07/inotifycollectionchanged-observable.html

    http://forums.silverlight.net/forums/p/213741/504976.aspx

    Yann

    Tuesday, April 26, 2011 4:44 AM
  • @Yann:  Thanks, pal.  This is very helpful.   

    The "reset" seems very ambiguous in terms of its implementation in the NotifyCollectionChangedEventArgs,  Likewise, a definition of "Paging" is extremely ambiguous.  The implementation of Interfaces within Classes can, logically, have some broad variations.  Point:  Each implemenation needs to be well documented.  Not just on its functionality, but, most importantly, the reasoning behind the functionality. 

    The entire subject of Collection management with LS needs to be documented, understood, discussed, and shared with SL/WPF/WP7 and MCV (Razor - or whatever will be the next generation of ASP.NET - seems to be some grey area here).

    Point: .NET biz app development has the same requirements across all platforms.  The solution to the requirements are different based on "perspective."  The focus on the solution will be slightly different with each platform.  Therefore, strengths and weaknesses.  Being able to look at base architecture implementatinos and standards across platforms makes a lot of sense.

    RE:  This interface does not report changes to the individual properties of any objects that are contained in the collection, only that changes have occurred at the collection level. To report changes to properties using data binding at the object level, use INotifyPropertyChanged"

    So . . . How do we manage the changes to the Grid columns?  A Grid row functions like a Screen section.  There is no reason why moving from control to control on a Grid is any different than moving from control to control within a Rows Layout, yes?

    Yann, is it correct to say that some of the IContentItemProxy control interface implementations in B2 are incomplete?  Do we know which Control implementations will be completed with RTM?

    We know that we have to wait for RTM before we have API documentation.  We don't know when RTM is.  What can we do to assemble a guideline that helps us until RTM?

    It is not planned to have an RC before RTM.  How do we (all of us), logically, know to work around all the problems with B2 so that our production apps don't have any problems?

    How do we build a detailed list of all changes that are necessary to migrate our B2 apps to RTM when RTM is available?

    In business, no function stands alone - everything is related.  Our job as biz app developers is to design systems that "do everything" based on understanding the big picture.  It seems logical that we would apply the benefits of our analytical business skills to designing tools to write business systems. 

    Point: As we go through each detail in building a business system, EACH related applicable issue is addressed.  So, when a phantom grid row is added to a development environment, the considerations for its implementation must be compared to the implementation of the AddNew button.  When we build a biz app, it is expected that everything is easy for the user.  That the system "molds" to the function of the worker's job to accomplish business goals.  Building LS is no different than building a biz app and implementing a biz app.  VS/LS is our "business application."

    Thoughts?

    Tuesday, April 26, 2011 6:56 PM
  • Hi Garth,

    "How do we manage the changes to the Grid columns?"

    I use INotifyPropertyChanged on the Collection.SelectedItem, removing any existing handler when the SelectedItem changes, adding my handler.

    		private void Collection_SelectionChanged()
    		{
    			var selectedItem = this.Adjustments.SelectedItem;
    			if (selectedItem == null)
    			{
    				return;
    			}
    
    			Dispatchers.Main.BeginInvoke(() => {
    					((INotifyPropertyChanged)selectedItem).PropertyChanged -= GridPropertyChanged;
    				});
    
    			Dispatchers.Main.BeginInvoke(() => {
    					((INotifyPropertyChanged)selectedItem).PropertyChanged += GridPropertyChanged;
    				});
    		}
    
    		private void GridPropertyChanged(object sender, PropertyChangedEventArgs e)
    		{
    			switch (e.PropertyName)
    			{
    				case "SomePropertyName":
    					//do something here
    					break;
    			}
    		}
    

    "is it correct to say that some of the IContentItemProxy control interface implementations in B2 are incomplete?"

    I don't know if I'd say that the implentations are "incomplete", but it's pretty hard work at times, working with so many "unknowns".

    So, yes, some LS-specific documentation would indeed be helpful. In the meantime, we have to struggle along, & find our answers through "hit & miss" & collaborative efforts.

    Yann

    Tuesday, April 26, 2011 11:51 PM