I would like to present a list of orders to the user. If the user double-click an order in the list, the order maintenance window will open and the BO will be populated with the primary key being passed to it. I have done this in a number of situations outside of the StratFlix-like application. Now, I would like to do the same but take advantage of the code already existing. The LaunchDialog looks like this:







How would I pass the primary key via the Activator.CreateInstance method? I'll start researching it and testing. Hopefully, someone here will be able to shave off some of my R&D time (so I can get to R&R quicker!).



Thanks!!

Bill

Bill,



One of the overloads of the CreateInstance accepts an array of objects. CreateInstance then looks for the constructor of the indicated type that best matches that array of objects:







Now say you have a dialogType of WidgetMaintenanceForm:







Now you could call LaunchDialog in one of two ways:







Hope that helps with the R&D...on to the R&R!

I was just wrapping up my testing and thought I would check back on the forums. Greg...thanks for responding so quickly! You and I were thinking a lot alike this afternoon. I pretty much did what you provided as an example. I did a couple of things differently. The first was the LaunchDialog method syntax. Mine looks like this:







The second was to (as you see in the snippet above) was to make the method public. From the MDI child dialog window, I need to call this method in the MDI parent form. That was the easiest way for me to do it. So, my resulting method call in the dialog looks like this:







I am using a DevEx grid to display the vendors. Either a double-click on the vendor in the grid, or a click of the dynamic action menu item will call this method and open the maintenance window directly to the vendor ready to be maintained.



I did handle the actual maintenance window's constructor slightly differently, too. Here is what I put together:







I am trying to override the Save/Undo auto creation in the action menu. Haven't quite got that right, yet. The rest seems to be working out quite well.



Almost time for that R&R...

I like the params approach. This means you don't have to have n overloads for all possibilities. I.e. if you then use LaunchDialog some other form (oh, say WidgetMaintenanceForm) and it has an overloaded constructor:



public WidgetMaintenanceForm(string itemName, int itemIdex, WidgetFormMode mode)



there are no changes to LaunchDialog:



LaunchDialog(typeof(WidgetMaintenanceForm), "Furry Widget", 342, WidgetFormMode.Edit);



Cool! I need to go update my LaunchDialog method!

I made one more tweak to my code to handle the launching of various forms. Instead of a different method for each ToolStripMenuItem (it was getting a tad messy in my project!), I decided to create a common method. In order for that to happen, I added a string to the Tag property of the ToolStripMenuItem. The string is the full name of the form that is being launched (e.g. "MyNamespace.MyFolder.MyForm"). I left the LaunchDialog alone (except for the earlier modification for passing some parameters). Here is the method I created:







Now, in the Click handler, all I need to do is point to this method. Works like a charm. At least, it made my day!!



Bill

Nice Bill!



Another way this could be handled would be to use a property provider, like a tooltip provider or a error provider. This would allow you to drop a component on a form that would manage using buttons (or any other UI elements desired) to open a form via the LaunchDialog method. You'd just set a property or two (type name, maybe some optional parameters, maybe an enable property). It would then manage the click event for you. If I get a minute, I'll do up a sample. I've used this sort of thing a bunch and it really makes life easy.

Thanks Bill.







Greg, please take 2 minutes you got me intrigued now, my LaunchDialog() is working fine, but I am always looking for better ways to incorporate and learn.

Edhy Rijo

OK, here's the sample. Notice that there is almost no code in the forms. The only code is in the MainForm to initialize the launcher to use the MainForm as the MDIForm.



Also notice that I am using delegates to deal with adding handlers to the form. This allows for a more flexible design, as you can swap out the handlers you add to each form opened as needed by each app.



The Yellow form is a blank form, ready for you to experiment. Drop on the LauncherProvider, add a button/link/toolstripbutton and set the FormType for the button/link/Toolstripbutton. Done.



You might want to experiment with extending the LauncherProvider to support menu items as well. If you check out the CanExtend method, you'll see how do that. One line of code should do it. (Though you'll want to see what is happening in the SetFormType method also, which is were the click event is setup for each extended control).



Another thing you might want to experiment with is to add another property to manage what happens if the form needs arguments. I was thinking that a cool way to handle this would be to add an extended property to indicate if the form needs arguments. Then raise an event, passing out the form type. Then on the form with the control being extended, you'd handle this event of the LauncherProvider, test for form type, and provide the arguments....kind of like ListView/ComboBox items do in SF (ListPopulating event).



Have fun!

Edhy, you might have missed this with the servers being down....

Hi Greg,



Yeap, I did and still on my browser I get the yellow/red warning about forum maintenance.



Will download now. I am reviewing my 1st SF project and found a lot of things to change will see if I can incorporate your technique in this project. Will report back later today....



Thank!

Edhy Rijo