New Posts New Posts RSS Feed: [COMPLETED] Widget View Template
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

[COMPLETED] Widget View Template
 Post Reply Post Reply Page  <1234>
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Topic: [COMPLETED] Widget View Template
    Posted: 25-Sep-2007 at 5:24pm
Ok.  The test was partially successful.  I was able to get past the casting problem.  Now, I am still trying to figure out how to get the toolbar to be enabled.  It has got to be related to SetControlViewToolStripAdapterCore() somehow.
Back to Top
Bill Jensen View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Jul-2007
Location: United States
Posts: 229 		Post Options Post Options   Quote Bill Jensen Quote  Post ReplyReply Direct Link To This Post Posted: 25-Sep-2007 at 6:23pm

As I mentioned earlier, ensure that the BindingSource for your ControlView is properly assigned to the BindingNavigator.
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 25-Sep-2007 at 8:49pm
From the ContactsView class:
 
[InjectionMethod]
public void InjectPresenter([CreateNew] DotNetControlViewWithToolbarPresenter<IBindingView> pPresenter)
{
    SetPresenter(pPresenter, mNavigator, mControlBindingManager);
}
 
Is this the right way to do this?
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 26-Sep-2007 at 11:05am

The culprit was in the new ControlViewWithToolbarPresenterBase.cs class.  I had the following:

/// <summary>ViewContext was set and is presumed ready with values.</summary>
protected override void OnViewContextSet() {
    base.OnViewContextSet();
    SetBindingManagerBindingSource();
    SetControlViewToolStripAdapter();
}
 
In the GridViewContextBase there was a slough of stuff that inaugurated the GridView.  Inside of one of the methods was a call like this:
 
GridViewToolStripAdapter.Configure();
 
Aha!!  I added the call to the OnViewContextSet() above.  Now, the data shows up properly with navigation to the additional entities.  Good stuff!!!
 
Alas!  There is always a cloud with every silver lining.  I assumed (ya, bad idea) that the add, delete and save buttons would appear in the toolbar, but they do not.  Another switch is hiding in there somewhere.  Now, where is that thing?
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 26-Sep-2007 at 1:14pm
Along the way, I found the DevExPageView.  I created a new ContactView2 and inherited from this control.  I passed it to the GeneralTabViewController and got the error that ContactView2 could not be converted to IBindingView.  Bummer.  That would have saved a lot of work...it has the add/edit/delete and alert messaging...sure would be nice.  Is there a way to do that, maybe?
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 26-Sep-2007 at 2:04pm
I found this method:  AddToControlViewToolStrip() in the DotNetNavigatorControlViewToolStripAdapter (adapted from the DotNetGridViewToolStripAdapter).  It has the AddEditButton, AddAddNewButton and AddDeleteButton methods that I want, but how do I get them to fire?
 
This is quite odd.  The DotNetNavigatorControlViewToolStripAdapter inherits from ControlViewToolStripAdapter in which the following is declared:

/// <summary>Add to the ControlViewToolStrip <see cref="UIExtensionSite"/>.</summary>
protected virtual void AddToControlViewToolStrip() {
}
 
In that same class is the Configure() method which has as one of its calls, AddToControlViewToolStrip().  That method is defined (with the add button methods) in DotNetNavigatorControlViewToolStripAdapter, not in ControlViewToolStripAdapter.  Shouldn't these add button methods be in that class rather than the class that is inheriting from it?  In the event that I don't want them implemented, I could override in the class that is inheriting from it.  Well, I may not have this square in my head, but if someone else could look at this and let me know what to do or how to think about it, I would really appreciate it.  The same structure is found in Cabana with the DotNetNavigatorGridViewToolStripAdapter (IdeaBlade.Cab.UI) and the GridViewToolStripAdapter (IdeaBlade.Cab.Interface).
 
Thanks!!
Bill


Edited by Linguinut - 26-Sep-2007 at 2:17pm
Back to Top
Bill Jensen View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Jul-2007
Location: United States
Posts: 229 		Post Options Post Options   Quote Bill Jensen Quote  Post ReplyReply Direct Link To This Post Posted: 26-Sep-2007 at 4:20pm

Sorry not to post sooner today--I've been out for some appointments and errands.

You've got a couple of things going in this thread which has become rather long.  At some point we should close this thread and start a couple of new ones.
 
Anyway, to address your most recent post:
 
First, the tool strip adapter is implemented as a classic template pattern:
 
GridViewToolStripAdapter is an abstract template class that delegates its implementation details to a concrete implementation class.  It always looks the same to its client class, GridView (or more precisely, GridViewPresenterBase).  In this case, Ward has provided only one concrete implementation:  DotNetGridViewToolStripAdapter.
 
Second, the template pattern is extremely common and occurs again:
 
GridViewPresenterBase is itself an abstract template that delegates its implementation to concrete classes, two in this case:  DotNetGridViewPresenter and DevExGridViewPresenter. 
 
Once the view context is set, the OnContextSet() method configures the grid view.  One of the steps is to invoke SetGridViewToolStripAdapter() that delegates to the concrete implementation of SetGridViewToolStripAdapterCore() which creates a new DotNetGridViewToolStripAdapter, passing the tool strip object itself, the binding source and the view context.
 
Immediately after calling SetGridViewToolStripAdapter(), GridViewPresenterBase calls its Configure() method.  Among other things, Configure() invokes AddToGridViewToolStrip() which is again delegated to the concrete implementation.
 
Your ControlView-based versions of these classes should work in exactly the the same way.
 
N.B.: The GridViewToolStripAdapter and DotNetGridViewToolStripAdapter classes have "GridView" appearing all over the place.  On closer examination however, almost all of these are just class, member and variable names. 
 
The only real dependency is on the view context being a GridViewContextBase and even that is only used to provide three items:
 
The binding source (actually available from the base BindingViewContextBase class)
 
The GridViewToolStripVisible flag.
and
The GridViewToolStripChanged event.
 
These last two could be made optional by moving them to an interface, IGridViewToolStripContext, then having GridViewToolStripAdapter check if the view context implements this interface and hook them up if so.
 
Once that's done, the dependency on GridView (and ControlView, in your case) could be eliminated and it becomes possible to add a tool strip to any binding view.  If there were a BindingViewPresenterBase class (there isn't) we could move the logic there but for now, we can just leave it in our specific base presenter classes.
 
This kind of refactoring is constant in a framework like Cabana.  We start with specific implementations for initial use cases (i.e., GridView tool strips in this case), then, rather than duplicating code, refactor to a more abstract implementation to cover more use cases.  In the process we eliminate dependencies and increase reusability.
 
My battery is going dead...gotta post this.
 
Hope this helps.
 
Bill J.
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 5:33am
Hey Bill,
 
No problem with your posting frequency.  I am glad whenever you can offer help.  I do wish that there were more of us out here, though.
 
This is getting to be a long thread; however, it is all related to my desire to create the control view widget with a toolbar.  I am at the very final stages of this journey.
 
Thanks a bunch for the bird's eye overview of the adapter classes.  I will work through this for understanding.  Unfortunately, the classic template is a relatively new animal for me.  I am still doing a lot of catch-up reading to get more acquainted.
 
Thanks, again.  I'll update here when I get more answers or have more questions regarding this.
 
Bill


Edited by Linguinut - 27-Sep-2007 at 8:57am
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 8:15am
Originally posted by Bill Jensen

Immediately after calling SetGridViewToolStripAdapter(), GridViewPresenterBase calls its Configure() method.  Among other things, Configure() invokes AddToGridViewToolStrip() which is again delegated to the concrete implementation.

 
Slowly wrapping my brain around this. 
 
The ControlViewToolStripAdapter has a protected virtual method defined called AddToControlViewToolStrip.  The class DotNetNavigatorControlViewToolStripAdapter is derived from ControlViewToolStripAdapter; therefore, has the implementation of the AddToControlViewToolStrip method.  When a call is made to ControlViewToolStripAdapter.Configure, the method AddToControlViewToolStrip is called.  This is where I get confused.  The abstract class then calls the concrete class to run the method defined there?  Is that right?  Does the protected virtual designation make a difference over the protected abstract designation?
 
Thanks.


Edited by Linguinut - 27-Sep-2007 at 8:51am
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 10:12am
I can walk the code.  Btw, I changed the virtual tag to abstract, then back to virtual--the code does the same thing either way.  The call is being made to the concrete class (as expected).  The buttons are being built.  But they are not showing up on the toolbar.  The UIExtensionSite  looks like it is being registered properly.  The buttons are being added to that defined site.  Nothing is showing up.  This remains a mystery.
Back to Top
Bill Jensen View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Jul-2007
Location: United States
Posts: 229 		Post Options Post Options   Quote Bill Jensen Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 10:19am
A quick refresher on object-oriented 101, C# style:
 
The ControlViewToolStripAdapter has a protected virtual method defined called AddToControlViewToolStrip. 
 
Correct.  It has an empty body.  The virtual declaration indicates that a child class may provide a non-empty implementation.  The protected modifier merely restricts the visibility to the base and child classes.  A virtual method can be public or internal, but private virtual doesn't make any sense.
 
The class DotNetNavigatorControlViewToolStripAdapter is derived from ControlViewToolStripAdapter; therefore, has the implementation of the AddToControlViewToolStrip method.
 
Correct, though it doesn't have to provide an implementation, since an empty implementation is provided in the base class.  If it were marked abstract in the base class, the child class would be required provide an implementation.
 
When a call is made to ControlViewToolStripAdapter.Configure, the method AddToControlViewToolStrip is called.  This is where I get confused.  The abstract class then calls the concrete class to run the method defined there?  Is that right? 
 
Yes, that's the meaning of the override modifer on a method; when the method is invoked, the implementation in the overriding method is called, even if the invoker thinks it is holding a reference to an instance of the base class.  
 
Does the protected virtual designation make a difference over the protected abstract designation?
 
If the child implementation were marked new (instead of override), then the child method will be invoked if the invoker holds a reference to an instance of the child class, but the base class method will be invoked if it is called on a reference to the base class.
 
Does this clarify things?
 
Bill J.
 
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 10:54am
I created a DotNet Grid View and added it to the customer tab controller.  No toolbar is displayed, so I cannot even tell if the buttons will show up.
 
Bill, can you verify that the add/edit/delete buttons, in fact, do show up on a DotNet Grid View?
 
Thanks!
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 10:55am
I much appreciate the quick refresher.  I wanted to make sure that my thinking was straight on these issues.  Thanks.
 
Btw, I am going to start a new thread regarding the toolbar buttons.
Back to Top
Bill Jensen View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Jul-2007
Location: United States
Posts: 229 		Post Options Post Options   Quote Bill Jensen Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 11:12am

In the DotNetGridViewToolStripAdapter (and presumably your ControlView version), the method AddButtonToGridViewToolStrip() contains the code:

if ( pHideIfNoCommandHandler ) {

CabFns.ResetStatusIfNoHandlers(WorkItem, commandName, CommandStatus.Unavailable);

Basically this hides the button if its attached command doesn't have a handler registered.
 
The ToolStripAdapter (and in fact the presenter that owns it) doesn't care what happens when a button is clicked--it merely sets up a command (with a name that includes the unique ViewId)  and fires it.
 
The handler for the command must be registered somewhere.  It remains a mystery to me where this is done for the detail grid view case.  However, the MasterDetailTabViewController contains this function:

/// <summary>Register CommandHandler for a Command on the detail view.</summary>

/// <param name="pCommandRootName">The root name of the CommandName to make (e.g., "Edit").</param>

/// <param name="pHandler">CommandHandler of this command.</param>

protected void RegisterDetailCommandHandler(string pCommandRootName, EventHandler pHandler) {

string commandName = mDetailViewContext.MakeViewSpecificId(pCommandRootName);

CabFns.RegisterCommandHandler(WorkItem, commandName, pHandler);

}

I can't find any invocations of this method, but at least it shows you how to register a command handler.  You'll need to register handlers for the button events (probably in your ContactViewTabController).

I'll try to get some more information out of Ward.
 
Bill J.
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 12:05pm
Here is the method in the DotNetNavigatorControlViewToolStripAdapter:

protected void AddButtonToControlViewToolStrip(ToolStripButton pButton, string pCommandRootName, bool pHideIfNoCommandHandler) {
  string commandName = ViewContext.MakeViewSpecificId(pCommandRootName);
  ControlViewToolStripSite.Add(pButton);
  CabWinFormFns.AddCommandToButton(WorkItem, pButton, commandName);
  if ( pHideIfNoCommandHandler ) {
    CabFns.ResetStatusIfNoHandlers(WorkItem, commandName, CommandStatus.Unavailable);
  }
}
 
What if I added the following into the above code?
 
CabFns.RegisterCommandHandler(WorkItem, commandName, pButton.Click);
 
All of the ingredients I need are right there while the button is cooking.  I am not sure how I would do this in the tab controller.
 
Bill
 
Note: pButton.Click cannot be used as the EventHandler passed in the argument.  The eventhandler must be presented another way.


Edited by Linguinut - 27-Sep-2007 at 12:09pm
Back to Top
Linguinut View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 394 		Post Options Post Options   Quote Linguinut Quote  Post ReplyReply Direct Link To This Post Posted: 27-Sep-2007 at 1:35pm
From what I can tell, I would have to implement the actual add/save/delete calls (EntityManager.SaveAll(), or something like that).  This kind of thing should already be wrapped up above this toolbar somewhere and accessible to it.  I do not want to rewrite any of the code found in the MasterDetailTabViewController.  Shouldn't it have "bubbled up" someplace else, already?  Well, I hope Ward can come to the rescue and point the way on this.  I do want to duplicate code unnecessarily.  If the wheel has already been created...
Back to Top
 Post Reply Post Reply Page  <1234>

Forum Jump Forum Permissions View Drop Down