Greg / Russel,



Don't worry, not hard time at all. I am able to read and sometimes get deeper with C#, just that I am still fairly new too .Net and learning everyday and now focusing on getting my applications to rock and roll and not time to sit down and learn C#, I still need to start working on my first ASP.net application using SF of course so time will come for C# as I have expressed here.

Edhy Rijo

Actually it hasn't been too much of a problem. 

I was really just giving Edhy a hard time!

I'm sure everyone on the forum appreciates Edhy's huge contributions! 

Russ Brown (Using C#2010/SQL Server 2008)

I usually try to post examples in the preferred language of the original poster, which in this case was C#. I usually don't have time to do both, but I'll be sure that when I start doing official examples, I do it in both. Also, it is really, really good to work in both languages, IMHO.



My approach to learning C# was first to read C# examples. Pretty quickly you pick up on the essence of the language. The next step is to translate a small C# projects to VB (then you're going in known direction). Then I started doing samples in C#, things like this. Finally, I created a small app from scratch. I chose to do something that wasn't database intensive (or a data app at all) so I could focus on the language and log some time with it. By the time I was done with that, I was really comfy with C#.



This assumes you have any time to learn a new language. BTW, I was a total VB guy to start with, and it wasn't horrible to learn C#. The good news is that most of what we do is .NET/SF, so learning C# is just learning a language, which is considerably easier than learning a framework (or at least takes less time).



In any case, I hope the sample provides is helpful.

Agree, but too many things in my plate right now to start switching language I feel pretty comfortable with VB and a decision factor to go with SF was the plenty VB sample code while IdeaBlade my 2nd choice have plenty C#, go figure!

Edhy Rijo

I wish everyone would just switch to C# and forget about it!

It would be helpful to always post solutions in both C#/VB.NET but I know that isn't really practical and too time consuming.

Russ Brown (Using C#2010/SQL Server 2008)

The message was hidden! I didn't mean for it to hidden.



No, I just that Bill started this and he uses C#, so my brain was going that way. I could translate it to VB.NET, but not likely until next week. Hopefully you can see how things work (all just .NET stuff) and how extender providers can be really cool.

Hmmmm, this is C# , are you sending me some hidden message so I finally make the move to C#?

Edhy Rijo

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

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

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!