|
Hi~
I am writting a windows service.
Can I set the properties such as log on identity in my new windows service in program? Then this property can be set automatically after installation of the windows service.
Also, can I write a UI for the windows service to call? For example, in the service solution, add a new project which contains a form. However, when I create a new instance of the form and show it on the service start (i.e inside the onStart() method, there are 2 statements : Form1 f1 = new Form1(); f1.Show(), the form has been shown but the form hang. The controls inside the form cannot be shown and the title of the form show that the form has no response. Is there anything goes wrong?
|
|
|
|
|
1) No, if you mean you want the installutil command to set the user stuff for you, you can't. Installshield, however, CAN do this for you if you write an install. I don't know whether the bundled Installer for VS.NET has this ability or not (but I doubt it).
2) Yes, you can put a form inside your service. However, there are a couple things you need to do. First, once "installed" go to Services, under Administrative Tools under Control Panel. Then go to your service and bring up the properties, go to the second tab and set the "Allow service to interact with desktop" option to enabled. Now, secondly, you OnStart needs to complete in short time. So, the best way to deal with this, is to put in a timer and then in the handler for Elapsed (or Tick or whatever) put in your form. Start the timer in Onstart and stop the timer once in the timer before showing the form. You should be able to continue normally.
|
|
|
|
|
Yes
Iam using package written by myself to install the service.
Can I set the property?
Also the form still cannot be shown normally
I set a timer and show the form after 10 sec after the service start.
Is there anything not right?
|
|
|
|
|
I tried a TON of different options myself and found NO WAY of installing a Windows Service automatically with those advanced options set (like user/password, etc.) EXCEPT by writing a full installation package in Installshield Developer. I actually had the company purchase Installshield for this purpose.
|
|
|
|
|
ohoh
Also the form still cannot be shown normally
I set a timer and show the form after 10 sec after the service start.
Is there anything not right?
|
|
|
|
|
Dis you set the "Allow service to interact with desktop" in the Properties for your service from within Control Panel/Administrative Services/Services?
Try this: When you create the form, instead of calling Show(), try this:
MyForm.ShowDialog();
MyForm.BringToFront();
|
|
|
|
|
Using ShowDialog() is ok
But why using Show() cause no response of the form?
Thanks
|
|
|
|
|
Hi all,
Is it possible for the following implementation ?
In all window applications, when the user select and right click some text
segment in the document window of the application, the context menu will have a menu item that is defined to be certain operation ? e.g like the "copy" operation for some text segment.
Thanks
|
|
|
|
|
Hi all,
I originally plan to write a https server from scratch in c# (coz I cannot
use those existing https server like IIS), but I find that the
https protocol itself is pretty complicated. So I may step back to implement some encryption measure on the message carried in the http protocol instead of using https server. And I would like to know are there any better method to have security measure on http transfer than implementing the encrytion measure by myself ?
thanks
|
|
|
|
|
Probably not. HTTPS is definately the best way to go. Barring that, however, you're going to need to write some encryption code. Check out:
http://www.mentalis.org/soft/projects.qpx
|
|
|
|
|
Hi,
I am trying to populate my datagrid with thread, since the data is quite large, so the user can still do something else while the data being populated in the background.
The data are retreived from SQL database.
So the form will begin populating datagrid when I click on Reload button.
This is what I tried :
<br />
private void btn_reload_Click(object sender, System.EventArgs e)<br />
{<br />
fthread_parts_daftar = new Thread(new ThreadStart(RefreshGridParts));<br />
fthread_parts_daftar.Priority = ThreadPriority.Normal;<br />
fthread_parts_daftar.IsBackground = true;<br />
fthread_parts_daftar.Start(); <br />
}<br />
<br />
private void RefreshGridParts()<br />
{<br />
ds_parts.Tables["tabel_parts_daftar"].Clear();<br />
partsDA.Fill(ds_parts, "tabel_parts_daftar");<br />
<br />
grid_partno.Refresh();<br />
<br />
fthread_parts_daftar.Abort();<br />
}<br />
This code gave me the following error :
An unhandled exception of type 'System.NullReferenceException' occurred in system.windows.forms.dll
Additional information: Object reference not set to an instance of an object.
When I removed the thread and just use fill command on the DataAdapter, it worked fine.
So I looked at the threading, and cannot find any mistakes on it.
I am a newbie in C#, and don't have many experience.
Please kindly help me to solve this problem.
Thank you very much in advance.
|
|
|
|
|
|
If child thread cannot fill datagrid, is there someway that I can popup a new window or form saying for the user to wait, while the datagrid is being filled?
|
|
|
|
|
New job, new surprises. This is everywhere in the C# apps here:
MyObject myObject = new MyObject();
if (!myObject.doSomething())
{
LogError(myObject.ErrMsg);
}
doSomething returns false when it encounters an error and saves the error message in the public property ErrMsg, which the caller will use to see the error.
What's wrong with that? Well I must admit I don't really know but it looks wrong to me. Isn't this what exceptions are for:
MyObject myObject = new MyObject();
try{
myObject.doSomething();
}
catch(Exception e){
LogError(e.Message);
}
When I mentioned it I was told throwing exceptions was too expensive. They do have some try/catch blocks but only for exceptions thrown by the .Net framework itself. All application errors are handled with this (at least for me) odd ErrMsg property.
How expensive is it to throw exceptions really? Is it reason enough to come up with a different error handling mechanism? Is it what they are doing such a bad thing that I should push to change it?
Cheers.
|
|
|
|
|
http://blogs.gotdotnet.com/cbrumme/commentview.aspx/d5fbb311-0c95-46ac-9c46-8f8c0e6ae561[^]
Short version, the CLR will always carry the baggage required to allow exceptions, and the cost of Exceptions is only high if they are likely to be thrown frequently inside tight loops. Otherwise, the potential cost of someone deciding they don't need to check the error code somewhere is much higher.
And seeing as you've just started, you should probably read that entire article, and present the most solid case you can, to impress your new employer.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Thanks for that Christian. Heavy reading for me, but interesting.
"the potential cost of someone deciding they don't need to check the error code somewhere is much higher"
That's my problem with c#'s unchecked exceptions. You can also forget to catch exceptions (or just be lazy and not do it), just like you could forget to check for error codes. I understood the argument that exceptions are only expensive when you, well, throw them, but I just don't see how unchecked exceptions help in not ignoring errors.
From the article: "It’s relatively easy to forget to check for a returned error code. It’s much harder to inadvertently swallow an exception without handling it".
I don't understand that statement. It might be hard to "inadvertently swallow an exception" but it's way too easy to ignore it (specially when you don't even know what exceptions a method could throw!). And that's just as bad as not checking for error codes ...
I want to present a case in favor of exceptions to my employer but this unchecked exceptions are giving me headaches. As you can guess by now I have a Java background ...
Cheers
|
|
|
|
|
elguaro wrote:
"It’s relatively easy to forget to check for a returned error code. It’s much harder to inadvertently swallow an exception without handling it".
I think what's meant here is that forgetting to check an error code is as easy as to forget to catch an exceptions, but both have different consequences. Whereas the unchecked error code just gets lost, the CLR will popup that an unhandled exception occured in your app.
So it's easy to forget the exception handling, but it's much easier to detect it.
www.troschuetz.de
|
|
|
|
|
elguaro wrote:
You can also forget to catch exceptions (or just be lazy and not do it), just like you could forget to check for error codes. I understood the argument that exceptions are only expensive when you, well, throw them, but I just don't see how unchecked exceptions help in not ignoring errors.
Because an error code ignored does nothing, an exception ignored brings your app to a halt.
elguaro wrote:
It might be hard to "inadvertently swallow an exception" but it's way too easy to ignore it (specially when you don't even know what exceptions a method could throw!).
You shouldn't ever catch Exception, only the Exception types that you anticipate and know how to deal with. If others get thrown, add them and work out how to deal with them.
elguaro wrote:
As you can guess by now I have a Java background ...
LOL - no, I didn't see that coming at all
The core issue is that if you don't catch an exception, you'll find out about it, and you'll be forced to write code to handle it. Consider exception handling to be error code checking with built in unit tests 
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Christian Graus wrote:
Because an error code ignored does nothing, an exception ignored brings your app to a halt.
That's if the exception is actually thrown. If I call a method and I never get an exception while developing I could forget to catch exceptions. You go whislting to prod and bang! Another unhappy user.
Christian Graus wrote:
If others get thrown, add them and work out how to deal with them.
Ok, so the deal is you add them as you find them. Again, you might only find one particular exception in prod. Had you been forced to handle it maybe something could have been done about it.
Christian Graus wrote:
LOL - no, I didn't see that coming at all
Yea that's why I thought I clarify it ... 
Anyway, I still think what they're doing here is wrong even with unchecked exceptions ...
Thanks for you comments ...
Cheers
|
|
|
|
|
elguaro wrote:
If I call a method and I never get an exception while developing I could forget to catch exceptions. You go whislting to prod and bang! Another unhappy user.
Well, that's what we like to call 'the real world' Any problem that doesn't come up in your obviously extensive testing/unit tests is going to be esoteric at best, and it's still better that you find out about it. There's nothing harder to diagnose than an error that only occurs on a client machine. With an exception, you'll actually know where the error is, instead of trying to diagnose ripple effects.
elguaro wrote:
Again, you might only find one particular exception in prod.
You do testing, right ? Most of the time, if you think about what you're asking a function to do, and/or read the docs, you should have a fair idea what exceptions are likely to be thrown.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Well we obviously work in very different environments. I have 3 years working in the Government (in Australia this is) and documentation is not that good. It doesn't exists really. And from what I've seen, developers do forget to catch exceptions or simply choose to ignore them. These are people
who are learning OO with C# and if the compiler doesn't force you to catch the exception you just don't do it. Even if you do your testing and the testing team do their thing afterwards, for some strange reason in my "real world" no matter how much testing you do, you can only expect the unexcepted in production. Then you get a stupid error that you could have had a chance of recovering from had you caught it. 
Christian Graus wrote:
Any problem that doesn't come up in your obviously extensive testing/unit tests is going to be esoteric at best, and it's still better that you find out about it
Frustrations aside  , just knowing that an error occurred is not good enough when you could have dealt with it and (why not!) recover. And no matter how extensive your testing is, sh*t will happen. You should assume it will too.
Christian Graus wrote:
if you think about what you're asking a function to do, and/or read the docs, you should have a fair idea what exceptions are likely to be thrown
Disagree. You shoudn't try to infer what exceptions are likely to be thrown just by looking at a method's name. You'd be implying implementation details.
|
|
|
|
|
elguaro wrote:
developers do forget to catch exceptions or simply choose to ignore them.
You are missing my point. If I choose to catch Exception e, then I will swallow all exceptions, this is an ACTIVE error I make. If I don't put a try/catch at all, then the program will *crash* because I forgot to catch an exception. Simple as that.
elguaro wrote:
for some strange reason in my "real world" no matter how much testing you do, you can only expect the unexcepted in production.
That's perhaps a sign that the test cases need to be broadened Even then, it's inevitable that some issues will be found by the client, that's just life. As I said, how much better for them to get an exception message that tells you exactly what went wrong on a production machine, rather than a general crash that leaves you spending hours looking at the code, trying to figure out how on earth the app got into a state so it did what they reported ?
elguaro wrote:
just knowing that an error occurred is not good enough when you could have dealt with it
But again, that's the point. We should be able to tell what errors are likely to occur in the majority of cases.
elguaro wrote:
You shoudn't try to infer what exceptions are likely to be thrown just by looking at a method's name.
Sorry, that's not what I meant. I meant that if I, within a function, try to open a file for reading (for example), I should be able to work out what exceptions are likely to occur within that API call, and therefore what exceptions I should be catching.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
Christian Graus wrote:
If I don't put a try/catch at all, then the program will *crash* because I forgot to catch an exception
You wouldn't forget if the compiler forced you to put in that try/catch. And that's one crash less in your system.
Christian Graus wrote:
how much better for them to get an exception message that tells you exactly what went wrong on a production machine, rather than a general crash that leaves you spending hours looking at the code
How much better not to have an error in the first place? Maybe the error was something you could have recovered from but forgot to put that try/catch.
Of course having unchecked exceptions is better than not having anything at all. What I'm saying is I'd prefer to have checked exceptions.
We could spend our lifes and never agree on this one ...
Thanks for the discussion ...
|
|
|
|
|
|
Given that DX9 is an utter joke, I'm using the Media Player control to play video files in my app. The thing is, I want to build a queue of files in my code, and play them, but it seems to do that, I need to load the file, wait for the player state to be set to ready twice, then I can play. This I did, and it works fine on my machines, but not on the clients. Does anyone have any info or know of a good source of info on maintaining a file queue using the WMP SDK ?
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
