CODEWITHSUNDEEP
visual-studiosilverlightinternet-explorerprintingdebugging
herzmeister
herzmeister

Reputation: 11297

Another knack on the "Dialogs must be user-initiated" Security Exception in Silverlight printing

I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:

Silverlight printing "Dialogs must be user-initiated" Security Exception

John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.

Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.

Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.

Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.

I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.

Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:

http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip

I wonder if anyone can reproduce?

Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?

Upvotes: 2

Views: 4061

Answers (4)

Dharamjit Chamba
Dharamjit Chamba

Reputation: 11

Try to remove

if(SightPaleceListBox.Items.Count > 0)

Upvotes: 1

Chui Tey
Chui Tey

Reputation: 5564

I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml

<Button x:Name="PrintButton"
   Content="Gotta print 'em!" Margin="8" 
   Click="PrintButton_Click" />

Don't feel bad about it. I did it last time through a misplaced Print inside a loop.

Upvotes: 1

Keren
Keren

Reputation: 81

I had the same problem and found out that the reason was this following line:

cnvsMain.Children.Remove(PrintPagePlaceHolder);

cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).

My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.

Upvotes: 0

AnthonyWJones
AnthonyWJones

Reputation: 189457

I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.

However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.

Upvotes: 1

Related Questions