Re: Forms & variables & suchlike - C# Discussion Boards

Forms & variables & suchlike

16-Mar-04 3:00

If I were you, don't use the xsl:for-each, use xsl:apply-templates instead. This does work great and gives you greater control over multiple views (using the mode attribute). Besides, if you're doing this in a .NET application/library, interoping with COM just to get your XSLt to work is too expensive, IMO, because all the calls must be marshalled.

Also, don't use //book since you're already at the root of the document (not the root element) - it causes the XPath parser to prepare for deep traversal and isn't as effecient as, say, using catalog/book or /catalog/book. As an example using xsl:apply-templates, see the example:

<xsl:stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output method="html"/>
  <xsl:template match="/"> <!-- Also serves as a catch-all so you don't
    have stray elements being output -->
    <html>
      <body>
        <table border="1">
          <tr><td><b>Author</b></td><td><b>Title</b></td></tr>
          <xsl:apply-templates select="catalog/book"/>
        </table>
      </body>
    </html>
  </xsl:template>
  <xsl:template match="book">
    <tr>
      <td><xsl:value-of select="author"/></td>
      <td><xsl:value-of select="title"/></td>
    </tr>
  </xsl:template>
</xsl:stylesheet>

Microsoft MVP, Visual C#
My Articles

iterate through enum

Christian Graus15-Mar-04 13:14

Christian Graus

15-Mar-04 13:14

Is there any way to for each through an enum ?

Christian

I have drunk the cool-aid and found it wan and bitter. - Chris Maunder

Re: iterate through enum

Christian Graus15-Mar-04 14:34

Christian Graus

15-Mar-04 14:34

Got it, thanks.

Christian

I have drunk the cool-aid and found it wan and bitter. - Chris Maunder

surgeproof15-Mar-04 10:54

surgeproof

15-Mar-04 10:54

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.

Re: Forms & variables & suchlike

Judah Gabriel Himango15-Mar-04 11:07

Judah Gabriel Himango

15-Mar-04 11:07

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); // pass this class
   
      Console.WriteLine(myVar); // outputs "12"
   }
}

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); // outputs 12
}

public void Modify(ref int i)
{
   i = 12;
}

---------------------------
He who knows that enough is enough will always have enough.

-Lao Tsu

Re: Forms & variables & suchlike

surgeproof16-Mar-04 8:16

surgeproof

16-Mar-04 8:16

thanks. i think i get it now! Wink | ;)

surgeproof.

Re: Forms & variables & suchlike

surgeproof17-Mar-04 6:38

surgeproof

17-Mar-04 6:38

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.

ProcessDialogKey and AppDomain

zilch15-Mar-04 9:37

15-Mar-04 9:37

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?

Heath Stewart15-Mar-04 9:55

15-Mar-04 9:55

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

Nemanja Trifunovic15-Mar-04 10:23

Nemanja Trifunovic

15-Mar-04 10:23

Heath Stewart wrote:
You don't have to unload the assembly to unload your plugin.

AFAIK, assemblies can't be unloaded anyway (unlike AppDomains).

Heath Stewart15-Mar-04 10:50

15-Mar-04 10:50

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. Roll eyes | :rolleyes:

(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

zilch15-Mar-04 10:34

15-Mar-04 10:34

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.

Heath Stewart15-Mar-04 10:48

15-Mar-04 10:48

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

zilch15-Mar-04 11:12

15-Mar-04 11:12

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.

Heath Stewart15-Mar-04 11:27

15-Mar-04 11:27

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

zilch15-Mar-04 12:43

15-Mar-04 12:43

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.

zilch15-Mar-04 13:09

15-Mar-04 13:09

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 Smile | :)

gratajik31-Jan-11 13:38

gratajik

31-Jan-11 13:38

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

Task Bar

SherKar15-Mar-04 7:40

SherKar

15-Mar-04 7:40

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

Re: Task Bar

Judah Gabriel Himango15-Mar-04 9:12

Judah Gabriel Himango

15-Mar-04 9:12

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

Re: Task Bar

Stefan Troschuetz15-Mar-04 9:51

Stefan Troschuetz

15-Mar-04 9:51

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.

Re: Task Bar

Heath Stewart15-Mar-04 10:01