|
I have a web page that needs to generate a report for download on a hosted server. Because of the complexity of the long running report I was thinking it would be best to have this run as a service. My thought was that it would work like this:
1. User initiates request for report through web page which sends request to service or application.
2. Service or Application generates report on server in background.
3. Service or Application saves report as PDF.
4. Service or Application emails notification upon completion.
At any time during the process the user should be able to visit a processing page that gives them the status of the report generation.
With that said, does anyone have direction for me on what to do with this? I have never built a web service or an external application for something like this, but rather embedded all my reports within my application so I am a bit lost on where to begin.
While I realize that this is not strictly C#, it is going to be a C# item, not an ASP.NET page. Any help is good help.
Cheers, --EA
|
|
|
|
|
There are other issues such as
- Exactly how long does it take to run
- What about duplicate request
- What happens if there is an error while it is running.
Presumably you are also assuming that the email will always reach the target.
If it was me.
1. Create windows service.
2. Post the report request into the database as a 'task' - invalidate duplicates.
3. Service looks for new requests.
4. Service process new requests.
5. Service posts results, either report or failure reason back to database updating the 'task' (so it won't run again.
6. Post process - like send the email with results.
7. Go back to step 3.
There might be some clever way to embed the functionality in IIS.
|
|
|
|
|
It depends how long is 'long'. For fairly long but not ridiculously so (or that processor intensive), you can just start a new thread in your web app to handle a report (or, better, use a thread pool, BackgroundWorker or Task to manage resources for you). If you need to farm it out to a different process, perhaps on another computer, then personally I would manage the communication through a TCP connection between processes. I wouldn't put the report status in a database table as that data is transient (only relevant while a report is being constructed), unless you need to audit the report generation pipeline. You could also do it with pipes or WCF or DDE (yes it still works!) or any other form of inter-process communication you're familiar with, depending on your OS.
However you manage that part, you then need a page which spawns a new report processing unit (thread or process) or adds a report request to the queue of an existing one, a page which will look up the status of an existing report (so you need to give your reports queryable application-unique IDs) and some communication between the web app and the processing unit to maintain information about the status of outstanding reports.
|
|
|
|
|
I want to open a msg file from disk and perform a Reply action like normal mailitem and display it to user.
Currently i have a datagrid where i show list of msg files .When i right-click on the grid we have context menu for Reply/ReplyAll/Forward option. If a user clicks on any of these action i should be able to open the mailitem in reply/replyall/forward mode.
In Outlook when we click reply for a mailitem it displays the mailitem to user...the same way i want the msg file to be opened to user in reply mode.
Any help is greatly appreciated ... 
|
|
|
|
|
Hi all,
I am creating the setup for my windows application,i want to include the expiry date for it that means whenever the setup is installed it should run for the 30 days after installation.
How can i do it ?
Is there any script in c# ?
Thanks in advance.
|
|
|
|
|
The way you could tackle this requires quite a bit of infrastructure you probably haven't got in place yet. Basically, when your application starts for the first time you would register it on a remote server (use a web service for this, and generate a unique ID for the app). Using this ID, every time the application is run, compare the expiry date with the current date at the remote server and return whether or not the application is run. The advantage of this approach is that it takes into account the user resetting their system clock trying to circumvent the time check.
|
|
|
|
|
Disadvantage for this strategy is that user must have a network connection which is always connected.
|
|
|
|
|
or at a site that blocks it (corporate firewalls etc)
|
|
|
|
|
Or they wireshark the "it's ok, run" response from the server, redirect the server domain to localhost, and then run the program forever using a fake server.
Or they'll just remove that check from the program, which is probably a lot simpler.
|
|
|
|
|
Or share the ID amongst several installations.
|
|
|
|
|
|
Better way is something like writing a hidden entry in registry or somewhere else.Keep updating the time at some events.Check whether the user is tampering with system Date , if he is doing some trick like this, expire the appln.Else run it for 30 days.
|
|
|
|
|
This isn't a better way, just another way. It also isn't secure, it is possible to download free registry watchers to see what is being changed. Checking whether the system date has changed is a problem too, as this can be done via the BIOS.
For .net apps there is no 100% way to secure against tampering, the best you can hope for is to stop the majority of users.
|
|
|
|
|
It's not worth the trouble. Just write the first version of the application, give it away for free, and see whether or not anyone likes it. If it becomes popular, maybe see about adding such things for version two. If not, at least you didn't waste your time.
|
|
|
|
|
I would write a registry value somewhere non-obvious on first use of the application with an encoded timestamp in it. You could also write an opaquely-named file into a system folder but since UAC it is not a given that you will be allowed to do that.
Any check of this kind you put on your application, particularly if it's written in .Net, will be pretty easy to find and remove, so don't put a lot of effort into it. But this kind of simple check is sufficient to tell people you'd rather they paid, and to protect the app from the vast majority of lazy users.
That said, you should strongly consider releasing software for free these days. Payware stands a good chance of turning people away, and the goodwill and potential future work you get from a quality free tool may well be worth more than the limited number of sales you'll get. And there's no need to try to protect free stuff.
|
|
|
|
|
hello guys... I have these two forms say From1 and Form2. Now I have some controls on Form1 and a datagrid on Form2. When I select a record from grid on Form2, I want this record to be shown on Form1.
Now I have got the data and saved it in the class - say DataClass.
DataClass data = new DataClass();
data.Id = Id;
data.Name = Name
. . .
But the problem is: how would I know user clicked the Select button or Close button, on Form2. Of course I wanna show data only when user clicks Select button. How can I do this? thnx
|
|
|
|
|
Have you opened Form2 using ShowDialog()? If you have, just check the result for DialogResult.OK which equates to clicking the OK button. Then all you need to is retrieve the data from a property that you have exposed in Form2 that contains the data.
BTW - please give your forms meaningful names; there is nothing worse than having to maintain a project where everything has default names because it means you have to open everything just to find a particular form.
Hmm, I'm not sure why you were voted 1. I have balanced the vote out somewhat.
|
|
|
|
|
Actually it does not have the button OK, it has the button Select. So I dont know how your solution us going to map here. Any guidance in this regard will be appreciated.
I actually have meaningful names for my forms but to keep the question simple, I said them Form1 and Form2
|
|
|
|
|
It doesn't matter what the text says - all you need to do is set its DialogResult to OK.
|
|
|
|
|
In teclick event of the grid , create a new instance of form1 with an overloaded constructor of Form1.make DataClass as the parameter , then Show form from there.Done
|
|
|
|
|
So now he has two form1 instances running. I don't think that's the effect he's after.
|
|
|
|
|
There are two ways to do this, either by public/internal properties in Form2 or passing an instance of a custom class derived from EventArgs. Either will require some kind of signalling to Form1 that the data is ready.
As previously mentioned, if Form1 shows Form2 via ShowDialog() then you can expose a property in Form2, set the DialogResult of Form2 to DialogResult.OK and check for that as a result of the ShowDialog() call, accessing the property.
This same procedure can also be done by subscribing to Form2s FormClosing event, although the dialog result is a better alternative as you have information relating to the success/failure of user interaction.
Alternatively, Form2 can raise a custom event subscribed to by Form1. If using this method (the one I prefer) then you can pass a custom event args class instance along with the event that contains only the relevant data - nice and clean and no need to expose properties in Form2 to the whole world.
|
|
|
|
|
Yes , He can write a custom event.
|
|
|
|
|
This type of question: communication of data or events between two forms, is among the most commonly asked and answered type of question on QA in CP.
The critical piece of information to have, imho, in considering a solution is to know under what circumstances Form1 and Form2 (to use your form names) are created:
1. Keeping a run-time created reference: if Form1 creates Form2, or Form2 creates Form1: at the moment of creating it: the Form that creates has a reference to the other Form it has created.
That reference can be stored, and, then, all public properties (and methods, or anything else that's public) can be accessed by the creating Form.
In terms of the question of knowing when Form2 is closed: if Form1 creates Form2: at the moment its created and assigned to some variable in Form1: you can immediately subscribe to Form2's Closing or Closed events, and add an EventHandler defined in Form1.
Here's a code example that demonstrates both the above. First, this is implemented in Form2:
public DataGridView Form2DataGridView { get; set; }
private void Form2_Load(object sender, EventArgs e)
{
Form2DataGridView = dataGridView1;
}And, then, this is implemented in Form1:
private Form2 NewForm2
private void Form1_Load(object sender, EventArgs e)
{
NewForm2 = new Form2();
NewForm2.Closed += new EventHandler(NewForm2_Closed);
NewForm2.Form2DataGridView.SelectionChanged += new EventHandler(Form2DataGridView_SelectionChanged);
}
private void NewForm2_Closed(object sender, EventArgs e)
{
}
public void Form2DataGridView_SelectionChanged(object sender, EventArgs e)
{
}1.a. The special case of using 'ShowDialog' for presentation of a Form is a special case of this: imho, nothing in the OP suggests 'ShowDialog' is being used. But, you have some good answers here, now, based on the assumption you use 'ShowDialog.' But, please note that you can create one, or both Forms, once, and keep a reference ... if one Form creates the other ... just as described above. Just re-use the reference to the instance of the Form in the ShowDialog mode.
1.b. The special case where both instances of Form1 and Form2 are created by some other entity: well, you can adapt what's suggested in points #1~2. ... edit ... This also is the case, imho, where you may explore the use of Interfaces to pass instances of Forms that implement the Interface cast to the Interface so you effectively limit what is exposed by the passed object. S. A. Kryukov often advocates this method in his QA answers: for example:[^]. ... edit ...
2. Injection: This usually means that one Form has a "vacant" public property, and another Form, when creating the second form with the property sets the value of the public property.
So, Form1 could have a public property of type DataGridView, and in Form2's Load event, Form2 could set the value of that property to the instance's DataGridView: but look at what is implied by that: Form2 must have access to the instance of Form1 ! To me this is "dog wag tail" implemenation: where this makes sense is if Form1 contains the DataGridView, and Form1 creates Form2, and Form2 needs access to the DataGridView on Form1. Then, this is easy because Form1 has access to the instance of Form2 at the moment it creates it.
2.a. I have to admit I have a strong bias against the idea of injecting a reference to a whole Class, or Form, into another Form or Class because I believe this is a violation of the principle of "separation of concerns."
Does Form1 really need access to everything public in Form2 ? If the answer is "yes," then I'd go for code as shown in the example above. But, if the answer is "no," then I'd modify Form1 code as shown above:
private DataGridView F2DataGridView;
private void Form1_Load(object sender, EventArgs e)
{
Form2 NewForm2 = new Form2();
NewForm2.Closed += new EventHandler(NewForm2_Closed);
F2DataGridView = NewForm2.Form2DataGridView;
F2DataGridView .SelectionChanged += new EventHandler(F2DataGridView _SelectionChanged);
}
private void NewForm2_Closed(object sender, EventArgs e)
{
}
public void F2DataGridView _SelectionChanged(object sender, EventArgs e)
{
}The difference in code may seem trivial: but, this implementation means that the only "exposed" object in Form2's instance within Form1's instance is the DataGridView on Form2, because the variable NewForm2 exists only in the scope of Form1's Load EventHandler.
2. Use of some "external" class to expose objects to other classes: You can create a public static class that maintains public Properties which can be set in each Form's 'Load, or 'Shown, EventHandlers, and then are visible to any Form in the same NameSpace. You could even set EventHandlers within that static class.
3. Raising events: This is probably the strategy most appropriate for the scenario you have described, particularly since it enables multiple subscribers to consumers (creators and users) of the instance(s) of Form2.
I've omitted code examples for #2~3, believing they are easy to find here on CP, within articles, tip/tricks, and QA, but if you have further questions, just ask.
"For no man lives in the external truth among salts and acids, but in the warm, phantasmagoric chamber of his brain, with the painted windows and the storied wall." Robert Louis Stevenson
modified 14-Dec-11 6:42am.
|
|
|
|
|
For any sort of complex application, both forms should be looking at some non-UI data model. So all Form2 should have to 'pass back' to Form1 is a selected index or an identifier for the model object that corresponds to the selected row.
Without knowing what the UI context of these two forms is (does Form2 spawn Form1 as an editor? are both forms top level forms? etc) it's hard to be more detailed than that. But the key point is that the data grid on Form2 should be a view on an IList<YourDataModelClass> (well, possibly, a BindingList or a BindingSource on a List) and the various controls on Form1 should be a view on the properties of a YourDataModelClass. You can achieve this with data binding or manually setting properties, and you'll probably want either the model class or a view-model to implement change notification (INotifyPropertyChanged) so that when you update things from Form1, Form2 also refreshes its view. If you're using WPF then you can just use Binding attributes in the XAML.
As Bill says this is a pretty common question in Q&A so you might want to search there and have a look at some of the recommended answers.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
