I have an small application that I have written that needs to be used/incorporated into about 6 larger pieces. Ideally I want to be able to open this smaller piece from each stand-alone application instead of adding the code to each one. This would allow for easier maintenance in the event there are changes they only need to take place in one application.
I have looked but I can't seem to figure out how I can open a second winform application from inside of one. Any help would be great.
Thanks
2 options.
1) If this small app can stand alone, meaning it can execute in some useful fashion without being spawned by a parent app, then use Process.Start(). Your application(s) that spawn this process may not be able to run in a partial-trust environment.
Process.Start("notepad.exe");
2) If the app is only useful within the context of the parent apps, say by being given objects or other arguments from the other apps, consider refactoring the small app to allow the form's project to be referenced by the parent apps. Then, your parent apps can simply create a new instance of the form and display it:
var childForm = new SmallAppForm();
childForm.Owner = this; //the child window will close when its owner does.
childForm.Show();
Though it's more code, it's generally easier and more foolproof to implement. The form can also be accessed and thus controlled from elsewhere in the app, and other functionality can be implemented without having to deal with the rather messy business of cross-process communication.
I'd look to make this a Library that's a separate project that you add a reference to from your other projects. Much cleaner than spawning child processes.
Related
Our application requires now that one of its components will be started in its own dedicated process.
I have just come across the AddInProcess class (from System.AddIn.dll)
Unfortunately i couldn't find any useful code examples or projects that use this infrastructure.
I am wondering what are its pros/cons against rolling our own out of process infastructure?
Our application uses .NET 3.5 (WinForms)
The component that should be loaded out of process is an execution engine that loads arbitrary user code and executes it.
One note to consider is the fact that this component that executes code, needs to pass back a Results object to the calling application.
I would say it depends on what sort of interface into the component you need.
If it is simple, i.e. the functionality needed is in a single function or two, you could just start a process to do it, passin an argument if needed.
If it is more complex, you could create a WCF host process and expose a service interface.
I have some GUI controls in WinForms application. For example i have log control which logs each progress application makes so i can debug quickly, currently all "databinding" is on MainForm. I can create separate control but still it is coupled too much with application logic.
I've got advice to use partial MVC pattern in which I will update some object which saves log items and log control will get to this object and load the data to control.
I don't know how to implement it, besides creating a Class which will hold the data I need to load.
I have problems with Threads as many processes in the application run in different Threads.
Do you know any example of this done in C#?
I read the thread Mr Moose links to, but what finally got me going was this: http://www.c-sharpcorner.com/UploadFile/rmcochran/implementing-the-passive-view-a-derivative-of-the%C2%A0model-view-control/ is part of a series the guy wrote on this exact issue. I am currently using this scheme and am quite happy with it.
I added a ObservableDictionary to some of my Model classes. Key based lookup is nice for a lot of cases.
He has a whole series of articles with different implementations that may be more suitable for you.
How can I expand the implementation of a wpf using my own custom classes? In particular, I want to create new C# classes on a wpf beyond the ones that derive from App.xaml and MainWindow.xaml. Should I add them directly on the project? If so, can I use references of the MainWindow elements inside them in order to tweak their functinality and add new tasks? Should they derive from the MainWindow class?
What is generally the most reasonable way to expand the implementation of a wpf to other new classes?
That is a rather broad question and where to place classes and from what classes to inherit are quite different problems. Both are ultimately a question of architecture though and what the right architecture for your application is cannot be answered here. It depends on what your application is supposed to do and how it should be done, all that should be planned out before doing anything with classes. You might want to read some smart book on topics such as software engineering and software architecture.
Ultimately you should get a good book on WPF, read it, and type all the examples into your editor. Simply trying to dive into an API with absolutely no example and no concept of how the architecture works is not going to get you anywhere very fast.
To answer your specific questions, though:
Should they derive from the MainWindow class?
No. To write the GUI for a WPF application, you rarely will have to use inheritance that isn't already written for you when Visual Studio generates a new app, a new window, or new user control.
It might make sense to use inheritance in your code somewhere, but rarely in the GUI code itself, and certainly not on the window or app level. The only manual use of inheritance will be for implementing custom WPF controls (the least frequent and most painful option for extending your GUI).
How can I expand the implementation of a wpf using my own custom classes?
It isn't clear what you're trying to do, so I'll try to cover all the cases.
UI
If you want a new application, usually you wouldn't derive from a specific application class at all, you'd just create a new WPF project (a whole program). Visual Studio will then create new classes for you that inherit from Application and Window.
If you want a new window, the same thing is true. You'd just tell Visual Studio to create a new window, and your classes would automatically be created for you, and they would inherit from Window.
If you want to add existing controls to a window, don't derive from anything. Go to the UI designer, and drag+drop controls from the Toolbox onto the page. Or edit the XAML for that window directly.
If you want to customize what happens when a user clicks on or works with a control, write event handlers for those controls. Or when you're comfortable about this, read up on data binding and the MVVM design pattern, since it will help you write cleaner programs.
If you're trying to customize the way your app or controls look, you'd usually use data templates, styles, user controls, and custom controls, in that order of frequency and difficulty. Except for custom controls, none of those involve manually written inheritance. When you add a User Control in WPF, Visual Studio will write a class that inherits from something, but you don't have to worry about that fact.
Non-UI
If you're trying to write the guts of your application, you probably should avoid writing any UI code.
It is a good practice to separate your UI from your main application guts. That way if a brand new technology comes out, you can strip off the UI, and throw the guts into a new program. Or if you decide to put those guts into a web page, that will also be possible.
You can reference this new code from the code-behind in the UI, or using the MVVM design pattern (which you should eventually read up on), but you should avoid mixing your UI specific code and your non-UI code as much as you can.
This means you won't inherit from any UI classes in order to implement the guts of your app.
We are using usercontrols in c# to have separate classes for features inside a tabm which works perfectly.
Our problem arises, when an usercontrol uses a Service Reference to any Webservice.
The first time dragging the control on the form works. The second time, the designer will show an error:
Could not find default endpoint element that references contract 'testSR.WebService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
The app.config contains the correct endpoint and it works as long as the calling code is inside the form itself, as soon as we move the code to the usercontrol, we have these problems.
I even tried to put the user control inside another project within the solution referenced it correctly and copied the endpoint/binding configurations from the app.config of the DLL to the EXEs app.config - then also the problem arises again...
It seems that user controls cannot reference webservices, but there should be a solution!?
EDIT: From my testing it now seems that user controls can use service references, but the VisualStudio Designer will only work for the first time, after that the programm still works, but the designer shows the error and when I ignore it, the designer removes the user control from the form. As long as I do not touch the containing form, the usercontrol is editable and working fine ...
I assume you are working with winforms. have a clear separation between UI and WCF and avoid this and other issues by making the usercontrol not to call wcf directly but call an intermediate class library which calls the service layer for you. In this way the WCF will be called by such class library and your UI will be isolated.
Actually thinking about this problem you are describing, are you requiring WCF connectivity at design time as well? if so you shoul probably avoid it by checking if running at design time in which case do nothing. removing the dependency and having your UI independent from Service References is anyway surely a good idea.
Only four years late, but I actually found a fix to the WCF issue when instantiating the service in the usercontrol.
As #DavidePiras stated, make a service class library and reference the binary .dll. (Call the .dll, Worker in this case for my answer)
In your user control, rather than instantiating the Worker class in the constructor, make a new method, call it LoadWorker in this case.
..
private Worker worker;
public CustomUserControl()
{
InitializeComponent();
}
public void LoadWorker()
{
worker = new Worker();
}
--
In your form where you are calling this userControl, but can't see it, then either in another method or in the constructor for the form, call usercontrol.LoadWorker().
--
public MyForm()
{
InitializeComponent()
customUserControl.LoadWorker();
}
An extra step I took from here was to close all open windows/files and do a Build Solution. Then reopen the form that the designer was failing on and it should be good to go.
Cause?
The form that worked at runtime versus what you saw in the designer window in VS20xx has to deal with what is instantiated at the runtime versus what occurs when the designer window is loading your user control. I don't know the fine details or the terminology to necessarily describe it, but that is what is causing it. I have found that throwing the loading of the WCF service into a separate method to be the easiest solution.
I hope it helps anyone else who runs by this answer now.
I'm working with this small web application (1 page) built by someone else that does a specific task after pressing a button on the web page.
Now the requirements have changed slightly, and we need to automate this to run weekly without the need of user interaction.
What would be the best way of doing this, minimizing the changes done to the code?
I was thinking on adding a console app to the project that then references internally the web app but that doesnt seem to work.
Or maybe converting the web app to a to console app, if that is actualy possible?
Is there any straightforward way of doing this?
Thanks
First, make sure the "specific task" is broken out from the Web application so it resides in its own .NET project. Even if this project just contains one class you're "separating concerns" between the Web-based UI and the task itself.
Then you can create another "wrapper project" to call this new project as you wish. A console application might well do the job -- you can run that using a Scheduled Task -- or you may prefer to use a Windows service.
It really depends on how well the existing code is structured. A common approach is to divide business logic from the presentation layer. In VS, it's normally done by creating a class library project and keeping all the business logic in there. A web application project would then just instantiate business logic classes and run their methods.
If it is done like that, you just need to reference the class library project. If, on the other hand, you have all the logic in the web application project, probably there's no fast way of doing that, as you're not supposed to instantiate Page classes manually (well, you can do that as well, but that is clumsy and not recommended).
So in that case, you should create a class library project and move there all the logic you need to use in your console app. I would imagine that would require quite a bit of refactoring.