|
Hiya. I'm using Visual C# - does anyone know how to declare a variable in say FrmMain - int myVar = 6; and then in a child of FrmTempTools set myVar to a value so i can read it again in my main form?
I have tried and can only get meesages such as undeclared variable in FrmTempTools.
Thanks anyone,
surgeproof.
|
|
|
|
|
Make the variable as public, or create a public getter property for the variable. Then just pass the Form instance to your FrmTempTools child.
public class FrmMain : Form
{
public int myVar = 6;
public FrmMain()
{
ChangeTheValue();
}
private void ChangeTheValue()
{
ChildOfFrmTempTools t = new ChildOfFrmTempTools(this);
Console.WriteLine(myVar);
}
}
public class ChildOfFrmTempTools
{
public ChildOfFrmTempTools(FrmMain mainInstance)
{
mainInstance.myVar = 12;
}
}
Also note you can use the ref or out keywords to pass the variable by reference, rather than the default of passing by value. For instance
public void Test()
{
int i = 6;
Modify(ref i);
Console.WriteLine(i);
}
public void Modify(ref int i)
{
i = 12;
}
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
thanks. i think i get it now! 
surgeproof.
|
|
|
|
|
On trying to follow through and adapt your code, i only get this error: No overload for method 'bladeblahFormName' takes '1' arguments. Any ideas?
thanks.
|
|
|
|
|
i'm building a plugin-based application and have just migrated to loading them in separate appdomains for nifty unloading etc.
one problem though,
when the plugin is launched in a separate appdomain, ProcessDialogKey is not called in the forms that some of the plugins have. As soon as I load them in the default AppDomain, it works flawlessly.
i use .net 1.1.
Anyone?
|
|
|
|
|
AppDomains separate the code completely. The only way to talk to each other is through Remoting (or some custom socket communication or something). Loading plugins into a separate AppDomain is not a good idea for this reason - they can't communicate with the application except through Remoting, which decreases performance since calls have to be marshaled across application boundaries.
There are many articles here on CodeProject about designing effective plugin type applications. You don't have to unload the assembly to unload your plugin. You simply need a way to dispose of the plugin, such as setting all instances to null or disposing it through the IDisposable implementation (you don't have to implement it, but it's a good idea) and clean-up the resource. In your app, just check if the plugin is disposed before using it. If you want to nullify its instances, just check for that.
If you must load these into separate AppDomains, then consider that each AppDomain cannot talk to each other except through Remoting (which means that keys processed in a plugin cannot be handled by the main application since they're in different threads). You'll have to devise some way to tell the host application that keys were pressed, perhaps by using a binary formatter through a TcpChannel and firing some event that the host application can handle (again, through Remoting). This is a kludge, though.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath Stewart wrote:
You don't have to unload the assembly to unload your plugin.
AFAIK, assemblies can't be unloaded anyway (unlike AppDomains).
|
|
|
|
|
Gee, really? I guess working with .NET since 1.0 beta 1, architecting large-scale enterprise managed applications, and being an MVP didn't teach me that.  (BTW, that's annoyed sarcasm)
I didn't say he could unload the assembly, only that he could unload (i.e., nullify or dispose the instance) the plugin. Unloading the assembly is often moot on modern machines.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
the only way to unload an assembly is to load it in a separate AppDomain, that i have read in many places.
but you made me think - is the reason the ProcessDialogKey is not called in the form in the plugin that it's sent only to the default AppDomain? then how do i catch it? the plugin is the only showing form in the program.
|
|
|
|
|
I didn't say that you can unload an assembly, I said that you can "unload" your plugin (by nullifying or disposing the instance of the plugin class). This is the common approach. See my sig - trust me, I know.
In order to work with the UI, messages must be sent to the control in the same thread that the control was created in. Since AppDomain are separate from each other, these threads are not accessible from another AppDomain. As I said before, process the input from the plugins and fire an event that can be remoted across application boundaries that your main application can handle. It's a lot of extra work for something so trivial, though. Honestly, does your app have so many plugins (which could all be in one assembly anyway, if needs be) that you must unload the assembly in which the plugin is contained?
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
first, i must say thanks a lot for the help, really appreciate it.
but the .dll file will still take up memory unless you unload the domain, doesn't it?
but i don't really understand what you mean about the UI.
everything in the form (created from the plugin in the separate AppDomain) work like a charm, EXCEPT ProcessDialogKey. you say "process the input from the plugins and fire an event that can be remoted across application boundaries that your main application can handle", but it is the plugins that want the event. the plugin have created the form, but the ProcessDialogKey is just not called when i press the TAB key etc.
really sorry if i misunderstood you.
|
|
|
|
|
zilch wrote:
but the .dll file will still take up memory unless you unload the domain, doesn't it?
Yes, but not very much depending on the size of the assembly (and how much IL has been JIT'd). On modern machines, this is very moot unless you plan on having 100s of plugins or something. Our flagship enterprise app uses dozens of rich plugins and - while everything is disposed properly - doesn't use much memory (as far as managed applications go). The majority of memory is used for instances of your classes, not the assembly or the JIT'd native instructions that are cached. If you ship several plugins for your application, consider grouping these classes together. The .NET Framework Class Library (FCL) doesn't have one class per assembly, does it? Having to unload the assemblies once the plugins that contain it is not necessary except in rare cases when memory is a problem (like on Windows CE platforms).
So you're saying the plugins are not getting ProcessDialogKey called in the forms that the plugins create? Are these modal or modeless dialogs? Are these dialogs created in separate threads? The forms are actually classes in the plugin assembly (loaded into a different AppDomain)? I'm just trying to understand what exactly is doing what.
Seriously, though, consider dropping separate AppDomains. Communicating within the same AppDomain is so much easier if you need your plugins to talk to either other or to the main application. The assemblies for plugins aren't loaded until the Type that needs to be loaded and executed (from that assembly) is needed anyway. Depending on how your application loads plugins (like ours works like the COM registry to enumerate plugins from the .config file but doesn't create them until they're needed), many of them might not get loaded anyway.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
i get your point with the memory, i'll think more about it.
but the real issue here is the ProcessDialogKey. Yes the plugins create the forms themselves. From the contextmenu on the NotifyIcon i press the name of the plugin. The hidden GUI responds to this and calls Execute() on the plugin in the other AppDomain. From here they create their own forms. They are modeless (Show). I tried making them modal now (ShowDialog) and strangely ProcessDialogKey did get called! However (!) this messes things up as other plugin forms already showing can't get focus if i don't close the modal one first (i only tried making one plugin modal, and i need many plugins showing at the same time). I don't create any threads anywhere (except before the call to Application.Run()).
I am considering dropping them now, but only then becuase of ProcessDialogKey. I have already made the whole infrastructure adapted for remoting. And yes you are right, its much easier with one AppDomain.
thanks again, very kind of you to help me.
|
|
|
|
|
i changed form.Show() in the plugin to Application.Run( form ) and now it works. That, I call magic. why does it work now? i don't see the connection, but then again win32 message loops are not my strong side 
|
|
|
|
|
Did you ever resolve this? We have a plugin system that really needs to be in a separate AppDomain, but when we place the plugin (which is a form) in its own AppDomain, ProcessDialogKey is never being called.
Thanks!
-Greg
|
|
|
|
|
hi
i want to hide the task bar from my app ??
and i want to maximze certain weindow i have its handle
if anyone knows plz tell me thanx
|
|
|
|
|
Use the SendMessage Win32 API to maximize another window. I'm not sure what you mean by hide the taskbar from the app ... if you mean don't show your app in the taskbar, you can use myForm.ShowInTaskbar = false;. If you mean make the taskbar invisible, you'll probably have to P/Invoke the Win32 API once again.
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
I think the following fits much better than SendMessage. The code shows declaration and usage.
[System.Runtime.InteropServices.DllImport("user32.dll")]
public static extern bool ShowWindow(int wndHandle, int nCmdShow);
ShowWindow(wndHandle, 3);
To set other window states than maximized read the help of the ShowWindow method in the Platform-SDK. The define-values which are mentioned there, can be found in Winuser.h.
|
|
|
|
|
Another way is to set Form.Bounds to SystemInformation. Also set Form.FormBorderStyle to FormBorderStyle.None. This will draw your window over top of the task bar. Note that this requires no P/Invoked calls directly, while the underlying effect is the same as other full-screen applications (including screen savers) that you see, since pretty much all the controls (including the Form class) encapsulates native APIs for Windows Management and Common Controls.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi,
I have a dataset object and I am filling it with the rows of a table.Now I assigned it to a datagrid object.I don't know the schema of the table.Now I want the schema of the table and the data type of each attribute in the schema.How do I get this?
Karteek
|
|
|
|
|
You can't get the schema from the DataGrid like you're probably hoping. You could construct an XmlDocument (or use an XmlTextWriter) to build a schema while enumerating through the tables and column definitions, but the easiest way is to create a typed DataSet by adding a new DataSet schema to your project and designing the desired schema in there. VS.NET can generate a typed DataSet class (with actual table and column names, as well as the proper column types and fewer look-ups). You can use this to bind more easily to a DataGrid. At the very least - if you don't want to use the actual typed DataSet - you'll have a schema that you can use for DataSet.ReadXmlSchema for a generic DataSet instance.
To bind to a DataGrid, though, you really don't need to know the schema in advance. You can always set the DataGrid.DataSource property to the DataSet instance (filled) and optionally set the DataMember to myDataSet.Tables[0].TableName. By default, columns are generated automatically. If you know the schema up-front - you don't even have to import any schema - you can pre-set the DataGrid.DataMember property to the table name and add a DataGridTableStyle to DataGrid.TableStyles that uses the same table name. Optionally, you can add various DataGridColumnStylesd to the associated DataGridTableStyle.GridColumnStyles collection property and set DataGrid.AutoGenerateColumns to false. See the documentation for any one of the mentioned classes and / or properties for more information and examples.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
ok i have a web page (csharp) and i calles a .dll written in foxpro to retrive information from a foxpro database but the problem is it caches the .dll and the database and any changes made outside of the webpage never get picked up by the webpag it looks at its cached copy of the database instead of going out and regetting the information
is there a way i can force it out of cache when i'm finished using it
chad
|
|
|
|
|
How are you caching it? Is the FoxPro code caching it? Surely there's settings or calls you can make to set up caching or even to disable it. If you're using the Page.Cache property, you should set up a CacheDepedency to invalidate it. There's also many other caching techniques for ASP.NET described in the .NET Framework SDK, as well as various articles in the ASP.NET Technical Articles[^] on MSDN.
If this doesn't quite answer your question, please be more specific about how you or your code is caching objects, and what is actually being cached.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Also, if it's caching the DLL, this should not be a problem. It's only loading and keeping the DLL in memory. The data being cached is the problem here. Either FoxPro is caching data, your DLL is caching data, or ASP.NET is caching data. If you actually change the ASP.NET web site (like recompiling or changing the Web.config file in the application's root directory), the web application is forced to restart, which will reload the DLL.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
its the web page cacheing the dll i use the dll for other programs and i don't have this cacheing proble and like you said i don't care if its cacheing the dll i care becasue its cacheing the database file
chad
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
