and strange is that the MessageBox.Show(Plugin.PluginName); indeed shows the name of the plugin, but code inside of ExecutePlugin() is aparently not executed.
I have a simple MessageBox.Show() inside the plugin's ExecutePlugin and the message box is not shown
Q:What does the derived class in C# tell to it's parent?
A:All your base are belong to us!
Try debugging your application. Put a breakpoint on the Plugin.ExecutePlugin statement, as well as on the first statement in the implementation of ICowPlugin.ExecutePlugin. As long as all your assemblies are compiled with the DEBUG preproc def (i.e., a Debug build) and loaded into your solution, you should have no problem determining if the method is actually executed (and it should be if no exception is being thrown, which doesn't seem to be the case since the next statement is executed) and if something is going wrong inside the method. An exception might be thrown in the implementation that you're also catching and returning from, so maybe you're not getting the results you want. Debugging this method will help determine the cause of the problem.
Hi, Im relativlly new to C#, so I dont really know what to look for.
THe method aparently works just fine and is "error-less" becouse when I compiled the plugin the compiller didn't return me any warnings or errors.
THe ExecutePlugin inside the plugin looksliek this:
I am just starting out with C# and want to know how can I tell what kinda of project the code was started from by looking at the code. and by project I mean when you create a new project, from the wizard....
Mostly, look at the class that's generated. If it extends System.Windows.Forms.Form, is most likely a Windows Forms property. If it inherits from System.Windows.Forms.UserControl is a user control project. If it just includes a static Main method and not much else, it's probably a console application. If you have a bunch of web forms (.aspx files) then you've got a web project. The best thing you can do is just start playing around with the different types and see what's generated, as well as read some of the articles in the .NET Framework SDK. There's also samples and tutorials out there.
Also, don't forget that CodeProject is a great resource and has many articles that often go in-depth into the technologies they target such as Windows Forms or ASP.NET.
If you mean to change the data source on which to report, see the ReportDocument.SetDataSource method. Designing your reports to use disconnected DataSet objects (especially strongly-typed ones that you can build report defintions from) makes reusing your reports on different systems and with different database easy!
We have an MDI application, where we would like to limit the possible locations of the MDI child forms.
Is it possible to set up some kind of borders that limit child location to some part of the client area?
Currently we simply move the form back inside the borders if it dragged outside of the borders. Unfortunately, this has some sideeffects (e.g. client form can be moved far outside the borders before the moved event is raised)
BTW: Is it possible to disable the scroll bars that appears on a MDI parent?
Yes, you can fix the Child form location MDI form.
You have to set the following properties in Child form
Form Border = none
Control box= false
Window Startup position=normal
I wrote an article a long time back on another site that I'm working on porting to CodeProject as a new series. See http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=388[^] for more information about hosting .NET controls in a web page. If exposed as COM control correctly (which the articles covers), you can even script them and handle events.
You can create a serialize class and encapsualte your class there and store your data in a XML file,for working with XML there are lots of projects in this site. Or if you do not want to store it in a XML,you can store that class in dat file.
I have a windows application which has a lot of controls placed all over the screen. I have developed it in screen resolution of 1024 X 768.
The problem is that when the resolution becomes more, the controls occupy lesser space on the screen with lot of free area. If the resolution decreases, each control requires more space on the screen and many controls go out of the screen with scroll bars being displayed.
Is there a way of dynamically resizing the form controls based on the resolution of Windows?
First: There are many applications that they fir for one resolution and warn it before run. But beyond that after your InitializeComponent() add a method that set the methods based on this resolution. You can get the resolution with SystemInformation.VirtualScreen property,and every control has its own Size property.
In addition to what Mazdak was talking about, you can also make use of the Dock property that most of the controls expose. Effective docking can help decrease those problems. If you're not starting with a clean surface, though, pay close attention to the order in which controls are added to the container's (ex: Form) Controls collectoin. They must be added in reverse order. For instance, if you have the "explorer layout" like so:
| | |
| | |
, you'll want a TreeView, Panel (to further dock additional controls), or some other control set to <cod>DockStyle.Left, then a splitter, then another control with DockStyle.Fill. The order in which these are added are in reverse of how I mentioned them:
When you add these controls to the designer for the first time (i.e., on a "clean surface"), add them in the order that I first mentioned above. VS.NET automatically adds the most recently added control as the first control in the array above.
Just play around with docking a little bit. Anchoring to opposing sides is also helpful but while docking and anchoring share some behavior in common, they are also used to solve distinct problems (they are most like each other when anchoring against opposing and adjacent sides, but docking can't move a control relative to adjacent sides).