AppDomain.DomainUnload never fired automatically - C# Discussion Boards

Re: Regenerate Print Preview

23-Apr-04 10:29

Is the PrintPage event handler called again? Put a breakpoint in your code and see. Otherwise, handle the StartPageChanged event on the PrintPreviewControl.

Microsoft MVP, Visual C#
My Articles

hxxbin26-Apr-04 4:14

hxxbin

26-Apr-04 4:14

I got a stupid idea:

<br />
this.printPreviewControl1.Document = null;<br />
this.pageSetupDialog1.ShowDialog();<br />
this.printPreviewControl1.Document = this.reportDocument1;<br />

and works

Multiple childs of MDI form

turist6923-Apr-04 7:03

turist69

23-Apr-04 7:03

Hi, I want to build MDI Application. I got success in 1st level of MDIChild forms now the problem is that if the 1st level of MDI child form open new forms those forms cannot be included as MDI child becoz those are child forms of the 1st level MDI child form. So could u plz tell me how to proceed in this, to build an application in which all forms as child forms of the main MDI form. or is there any other wayout. Thanks for ur support.

Re: Multiple childs of MDI form

Heath Stewart23-Apr-04 7:21

Re: Multiple childs of MDI form

23-Apr-04 7:21

Whenever you create a new MDI child form, just set the MdiParent property to the main form. So, if a child MDI form created a new child, it's MdiParent is what you'd set as the new form's MdiParent.

See the Form.MdiParent property documentation in the .NET Framework SDK for more information.

Microsoft MVP, Visual C#
My Articles

turist6923-Apr-04 8:00

turist69

23-Apr-04 8:00

Thank you, i got it running!

frmDlabMenu cpForm = new frmDlabMenu();
cpForm.MdiParent=this.MdiParent;

cpForm.Show();
this.Hide();

AppDomain.DomainUnload never fired automatically

VizOne23-Apr-04 6:16

VizOne

23-Apr-04 6:16

Hi!

In my app I'd like to execute some code when an AppDomain is unloaded. I expected AppDomain.DomainUnload to be suitable for this, however the event never gets raised automatically - only if I call AppDomain.Unload with that AppDomain.

Example:

class Class1
{
	static void Main(string[] args)
	{
		// subscribe to current domain
        AppDomain.CurrentDomain.DomainUnload += new EventHandler(CurrentDomain_DomainUnload);		

		// and for testing to another domain:

		AppDomain domain = AppDomain.CreateDomain("Test");
		domain.DomainUnload += new EventHandler(CurrentDomain_DomainUnload);

        // if I uncomment this, the event is fired for 'domain':
		//AppDomain.Unload(domain);
	}

	public static void CurrentDomain_DomainUnload(object sender, EventArgs e)
	{
        Console.WriteLine("Unloading appdomain");
		AppDomain domain = sender as AppDomain;
		if(domain != null)
			Console.WriteLine("... unloading domain is: " + domain.FriendlyName);
	}
}

I find this quite irritating. How can I implement some kind of per-AppDomain shutdown function?

Thanks in advance. Regards,

Andre Loker

Re: AppDomain.DomainUnload never fired automatically

leppie23-Apr-04 7:00

leppie

23-Apr-04 7:00

What about the ProcessExited event?

^{top secret AdvancedTextBox}

Re: AppDomain.DomainUnload never fired automatically

VizOne25-Apr-04 8:30

VizOne

25-Apr-04 8:30

ProcessExited only works for the main AppDomain (and even then, I find strange bevahvior to occur).

Regards,
Andre

P/Invoke and strings

Dominik Reichl23-Apr-04 6:04

Dominik Reichl

23-Apr-04 6:04

Hi!

On www.pinvoke.net I've read this:

[DllImport("shell32.dll")]<br />
static extern IntPtr ShellExecute(IntPtr hwnd, string lpVerb, string lpFile, string lpParameters, string lpDirectory, int nShowCmd);

And now I wonder:
1) does this work? "ShellExecute" doesn't exist in shell32.dll, only ShellExecuteA and ShellExecuteW.
2) If it works: which one (A/W) will .net choose?

So we come directly to the second question: the "string" type. Is this type a Unicode or ANSI string? Is the type dependent on the system the .net interpreter runs on (i.e. on Win98 it would be ANSI, on WinXP Unicode) ?

What I wonder too: what if we want to use a function like GetWindowsDirectory? This function wants a pointer to a string buffer which will receive the string. Well, now in C# we just declare "string s", without specifying any size of the buffer... Any way to allocate a string which can hold a specific amount of characters we can define manually?

If you know an excellent page on C# strings, please tell me Smile | :)

Thanks in advance and best regards,
Dominik

_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)

Re: P/Invoke and strings

Heath Stewart23-Apr-04 6:11

Multithreaded shared remote object ?

23-Apr-04 6:11

First, also add the CharSet=CharSet.Auto to your DllImportAttributE so that the strings are marshalled correctly. The CLR will pick the ANSI or Unicode (A and W endings, respectively), based on the current platform (Windows vs. Windows NT). If you ever wanted to call one of these specifically, you can set ExactSpelling to true.

Microsoft MVP, Visual C#
My Articles

Gangren23-Apr-04 5:50

23-Apr-04 5:50

Hi,

server side, I got a class containing a method like this :
DB_Access_Class() : MashalByRefObject
public string Execute_Query(string query)

The DB_Access_Class instances got infinite lease time.
The goal is to share the same instance between all clients.

client side, I got a proxy (singleton mode) on a remote DB_Access_Class
Now, i want several Clients to be able to run Execute_Query at the same time.

I don't care (and would even prefer actually) if the client is locked while waiting for server answer.

But i don't know the best way to implement this and can't find any example on the net.

Is there any way to implement this without using asynchronous calls ?

Thanks,

Etienne.

Heath Stewart23-Apr-04 6:14

23-Apr-04 6:14

You want the same client to execute the remote method multiple times at once? Or do you want multiple clients (i.e., multiple processes, perhaps even on different machines) to call it? The latter is already taken care of for you, which is why you should internally lock any resources if appropriate in your remote method.

If you want the same client to call it multiple times asynchronously, what's wrong with just calling it asynchronously? Otherwise, you can always create several threads, each of which would call it, but asynchronous method calls give you a little more control about when to receive the output of the method as well as polling options, which you'd have to add functionality for if you just used threads.

Microsoft MVP, Visual C#
My Articles

Gangren23-Apr-04 6:24

23-Apr-04 6:24

Heath Stewart wrote:
You want the same client to execute the remote method multiple times at once? Or do you want multiple clients (i.e., multiple processes, perhaps even on different machines) to call it? The latter is already taken care of for you, which is why you should internally lock any resources if appropriate in your remote method.

Indeed, it's about multiple clients, each of one doing 1 single call at a time. But from the tests i ran, here's what happens :
Client 1 calls remote_method
Client 2 calls remote method
remote_method takes 30 seconds to complete and returns result to Client 1
remote_method takes 30 seconds to complete and returns result to Client 2

So Client2 will wait 60 seconds before getting his result, which is not acceptable in my case where i'll have up to 15 clients calling the service. I need the server to treat requests simulteanously, which is why i need him to create a new thread on each call.

I just don't know the best way to implement this, and if i absolutely need asynchronous dialog using deleguates (which would require to have a MBR object client-side too, from what i understood)

Thanks for quick reply though, i really appreciate Smile | :)

Etienne.

Heath Stewart23-Apr-04 6:35

23-Apr-04 6:35

The client really has nothing to do with yor problem in this case. If the server is configured as a singleton, it should be able to service both calls simultaneously unless you're using locks within the implementation itself, and asynchronous calls won't solve this problem since the whole point of locking resources is to synchronize access to them.

As far as what you have client side, it's still a proxy - an MBR object - that proxies calls to the remoting object. You can't proxy calls without that. The same is true for COM. You still have a proxy on the client which you get either through a common assembly with a shared interface or using a tool like soapsuds.exe.

A lot of this also depends on how the WKO is hosted on the server.

Microsoft MVP, Visual C#
My Articles

Tom Larsen23-Apr-04 10:06

Tom Larsen

23-Apr-04 10:06

There is something else going on behind the scenes if it really takes 60 seconds for the other second client to get an answer.

When remoting is configured on the server side as a Singleton there is one and only one AppDomain that holds the instance of the remoting object/function. Any number of clients can make calls into the remoting entry point without blocking. So I am wondering if there is something in the server that is blocking. In fact I wonder if you have race conditions. "Singleton" provides no "thread safety". Without further information its only speculation.

Gangren23-Apr-04 12:59

23-Apr-04 12:59

Thanks a lot for your answers.
Seems that i have a glitch in my code which makes the server unavailable to other clients while processing request from one of them.

Here is the simple example i'm trying to get working :

Interface
Server
Client
Projects

I must have something wrong in there, but i can't figure out what...
Code is really simple, i don't even have any exception handler or anything, but i could have missed something...

If you try it out, you'll see if you launch 2 clients and call request from both of them, one (the first) will be done in 10 seconds approximatively, and the other will take twice as much.

Thanks again for your interest !

Etienne.

Tom Larsen29-Apr-04 11:07

Tom Larsen

29-Apr-04 11:07

Sorry for the delay in responding. Hopefully its not too far out of context.

Just glancing over your code I already see two places where deadlocks can occurs. This is why I said that Singleton have no thread safety at all. You don't need to put locks anywhere in your code if avoided using Singleton in the first place.

The fundemental problem is the lock inside of the the for loop. Don't put it there. Place around the entire loop and set.

I'm not sure why these are implemented this way but I implore you to reimplement the remote objects to be either SingleCall or client activated. Since you are trying to remember instance data, I recommend client activated.

Gangren29-Apr-04 11:22

29-Apr-04 11:22

hi, thanks again for your reply
I've been told on msdn newsgroup that singleton were supposed to spawn a new thread upon each call but that they actually did not, and this is apparently a known issue.
I've been adviced to look into genuine channels components, and they fit perfectly for what i need so i'll be using those
I have tried the same code i posted without any lock, to no avail.
I don't think the problem comes from locking, and i'd rather use singletons since i'm trying to build a DB access service, with several buffers acting as a proxy both for reading and writing.
(for instance, certain tables such as parameters tables will only be read once and for all and then stored in server memory, etc...)
And since i also need easy broadcasting (when parameters change) genuine channels do the work just fine.

Thanks again,

Etienne.

Gangren27-Apr-04 20:00

27-Apr-04 20:00

Hi,

Actually from what someone told me on MSDN newsgroup, the Singletons should spawn a new thread upon each call, but they do not. I've been told it was a known issue.

Etienne.

Print Preview

GoodQuestion23-Apr-04 5:18

GoodQuestion

23-Apr-04 5:18

I am making custom print preview with PrintPreviewControl().I am having struggle with to change other pages from first page. I am trying to click a button to change next page,but I cant get anything change. I tried to search other ways and ran out of ideas. What are your suggestions?

public class CPrintPreviewDlg : System.Windows.Forms.Form
{
public CPrintPreviewDlg()//initialize
{
CustomPreviewDialog();
printPreviewDocument.PrintPage += new PrintPageEventHandler(Part_PreviewPage);
}
public void CustomPreviewDialog()
{
printPreviewDocument = new PrintDocument();
printPreviewDocument.DefaultPageSettings.Landscape = true;
printDocument.DefaultPageSettings.Landscape = true;
PrintPreviewCtrl = new PrintPreviewControl();
PrintPreviewCtrl.Enabled = true;
PrintPreviewCtrl.Name = "Detail Preview Page";
PrintPreviewCtrl.Dock = DockStyle.Fill;
PrintPreviewCtrl.UseAntiAlias = true;
Controls.Add(this.PrintPreviewCtrl);
PrintPreviewCtrl.Document = printPreviewDocument;

}
private void OnNextPage_Click(object sender, System.EventArgs e)//click button for //next page
{
printPreviewDocument.PrintPage += new PrintPageEventHandler(Part_PreviewPage); //dont work
}
private void Part_PreviewPage(object sender, System.Drawing.Printing.PrintPageEventArgs e)
{
if(PrintSurfaceViewList2.Count+1 <= 0 )//rid +1
{
return;
}
m_Grfx = e.Graphics;
m_PageSize.Height = (float)e.PageBounds.Height;
m_PageSize.Width = (float)e.PageBounds.Width;

float fCurrentHeight = (float)e.PageBounds.Height;
float fCurrentWidth = (float)e.PageBounds.Width;
e.HasMorePages = true;

if(m_nPage < PrintSurfaceViewList2.Count)
((CPrintSurfaceView)PrintSurfaceViewList2[m_nPage]).DrawPrintView(e.Graphics,fCurrentHeight,fCurrentWidth);
else
{
//PrintSurfaceView.GeneralInfoPrinting(e.Graphics,m_nPage,m_strJobName,m_strGroupName,m_strSection);
}
m_nPage++;
if(m_nPage >= PrintSurfaceViewList2.Count+1)
{
e.HasMorePages = false;
}
}
}

Re: Print Preview

Heath Stewart23-Apr-04 6:09