iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
It seems that adding the dummy printer only worked in the development environment and not on the production server. Why this is, I don't know. It is likely related to increased security in the production environment. We will remove the dummy printer from production and use the suggested code fix to allow exporting of the grid. Unfortunately, this is the only option left available to us. I must add the code that you suggested to 315 grids throughout our project in order to re-instate the exporting functionality that we had with WebGrid 3.5 but that we lost when we had to go to the WebGrid 4.0 version.
protected void wgSearchResult_PrepareExportExecute(object sender, ISNet.WebUI.WebGrid.PrepareExportExecuteEventArgs e) { DataDynamics.ActiveReports.ActiveReport report; report = (DataDynamics.ActiveReports.ActiveReport)e.GetType().GetProperty("ReportObject").GetValue(e, null); report.Document.Printer.PrinterName = ""; }
This code seems to work whether the web server has printers installed or not.
Sorry, but I can not reproduct your issue. From what I see, the error is not occur on the coding. It seems that something wrong with the printer of yours. Have you tried to turn off your printer?
This error is difficult to reproduce on a development computer because on a development computer, the computer is a client machine and a server at the same time.
This error is trying to say that the server where the website is running doesn't have a printer. As silly as it sounds, you must have a printer on the web server just to allow the exporting of grids. At least you don't have to have a real printer on the web server, you can install a dummy file printer and it will work.
To confirm this problem, on a development server, remove all printers, every last one of them. Now try to export the grid from a remote client computer (that computer can have printers or not, it doesn't matter). Then, install a file printer on the development server and you can immediately export grids when the website is accessed from the remote client, you don't even have to restart the server.
I hate having printers unecessarily added to production servers, but we had to do this just to support exporting from grids. We added one file printer as follows:
Printers
à
Add Printer
Local Printer
Select port “FILE: (Print to File)”
Manufacturer “HP”, Model “HP 2500C Series PCL5e” (the printer model that you use doesn’t actually matter)
Name the printer
Do not share the printer
You do not want to print a test page
Finish
I have attached an example project. in the "wgResults_InitializeDataSource" event handler, uncomment each of the options to try them out.
When setting the DataMember on the grid, it must be changed on the web grid and on the root table at the same time.
The initial configuration is for an object collection example. All exports work except XML.
Change the configuration for DataSet example and you will see that all exports work including XML.
There is a way to recreate the problem. If your data source for the grid is a DataSet then in "DataMember" you are required to identify which table is used as the data for the grid. When you specify DataMember then that name is also the name used in the generated XML element name.
Now change the data source to a collection of objects instead of a DataSet. For an object collection you cannot specify a DataMember in the Grid properties, if you try then you get an error. But that means that the name is now blank, an empty string, and the Grid can't set the XML element name to a blank string. That is what the error message is trying to say.
This has happened for me on Client-side export, I haven't even tried Server-side export but theoretically it should have the same problem.
Options for the developer:
Interesting side note (this has no direct bearing on the problem at hand); using a previous version of the WebGrid, the developers on the project that I am working on found this problem and wrote some horrendous code to side-step the issue. Basically, they assigned the object collection to the datasource of the grid. Next they cast the datasource as a DataSet from the grid back into a new variable (this was possible in the old grid because it would internally build a DataSet from the given object collection). They then set the name property on the first DataTable in the DataSet variable and then rebound the variable to the web grid's data source. It worked for them but the new verion of the grid (quite correctly) doesn't do this automatic DataSet generation so my project can't run using the old kludge on the new WebGrid. I have already removed the kludge because it throws exceptions (and because I really hated it) but that leaves me without an "Export to XML" option for users. They have been told that it had to be removed and might be returned in a future release.
I have decided on option 1 for now, but it would be nice to have the XML functionality in the future.
HTH to find the issue (perhaps there should be a default behaviour so that if the DataMember is blank then default to something else for an element name for the XML output ... like the grid's name ... or "Data" ... or the page name ... or allow the developer to provide a DataMember name for object collection data sources for the sole reason of XML support).
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname
Creating your account...