|
FYI: Window Service does not have any User Interface. You cannot even give message
while running window service.
The only way to track status or give message is by using Event Log.
Use System.Diagnostics.EventLog namespace and write log entry and do
whatever you want using it from window service.
HTH
Jinal Desai - LIVE
Experience is mother of sage....
|
|
|
|
|
Another good idea is to have an application that works as a monitor and gets the feedback from the service, since you can use sockets and you can use Window's message queue.
Or you can use a smpt client to send e-mails reporting service problems.
|
|
|
|
|
Jinal Desai - LIVE wrote: The only way
three words to avoid.
|
|
|
|
|
Jinal Desai - LIVE wrote: You cannot even give message while running window service.
That’s not entirely true, Interactive Sevices[^], so long as you're using XP
If you want to send a command to a service you can override the OnCustomCommand[^] method and use the ServiceController.ExecuteCommand[^] method to send the command.
People are more violently opposed to fur than leather because it's safer to harass rich women than motorcycle gangs
|
|
|
|
|
|
I'd not reccommend doing so, better is stick with some nlog or something like this. But if you really really need to, use the MessageBox.Show overload that allows you to specify the:
MessageBoxOptions.ServiceNotification
The message box is displayed on the active desktop.
The caller is a service notifying the user of an event. The function displays a message box on the current active desktop, even if there is no user logged on to the computer.
But generally it is considered a bad practice of displaying messagebox directly from the service. I'd stick with some logging solution.
|
|
|
|
|
Hello All,
For the past few apps, I have used XML files to store user preferences and other program related data. Lately, I've been thinking about transitioning to registry keys for storing program values.
My two main reasons are:
1. They are lightweight.
2. More concealed from the user.
However, I've read that issues can arise between 32bit and 64bit machines.
What is the general opinion on using registry keys vs XML?
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
I would any day go xml configuration.
Advantage is portability. You can just copy paste your application directory and you are ready to go.
As far as security is concerned and you do not want user to tweak it, better encrypt it
Manas Bhardwaj
Please remember to rate helpful or unhelpful answers, it lets us and people reading the forums know if our answers are any good.
|
|
|
|
|
I would rather the user not see it all. I agree that being portable is a great reason to use XML.
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
You are correct regarding the 32 bit/64 bit issue. The keys would be stored in separate points in the registry, however this should not be a problem generaly. The only issue is if you create registry keys as part of your installer (which is always 32 bit) then they will not be available to the appliction running in 64 bit. However if your app just generated the keys if missing then there is no problem.
As the other poster said, use of the registry makes you application non-portable, but that may not be an issue.
The main question should be, do you need secure storage of this information? If the answer is yes, then encrypt it and store it in the registry. If the answer is no then xml is the easier, quicker and more simply manageable route to take.
|
|
|
|
|
The Man from U.N.C.L.E. wrote: (which is always 32 bit)
Not true as of Windows Installer 2.0 when 64-bit support for IA64 platforms was added. That support has since grown to cover everything 64-bit available today.
|
|
|
|
|
Personally I hate Windows registry. I would stick with XML. Issues could arise from different machines but if you are accessing the registry locally then it shouldn't be a problem. What I am saying is if you develop a x86 application it will read from the x86 (wow6432node) on a x64 system.
Also I noticed you are trying to keep it away from the user. Just because it is in the registry doesn't mean it is secure. I would stick with XML and just encrypt your values and decrypt them in your application. This way a user cannot read it.
You could also run into permission problems using the registry. I've seen problems where people were running McAfee and it did some weird stuff with not letting values in the registry being edited/removed.
|
|
|
|
|
I use XML for simple things and a database for more complex things.
The registry is evil.
|
|
|
|
|
All of these answers have been great. I think I'll stick to XML.
PIEBALDconsult wrote: The registry is evil.
I'll stay away from the curse. 
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
It was repeated on the forum several times. Registry is bad. You don't know if your application's user will be able to access registry. Only administrators can do it (I don't remember how it was on Windows XP, but I'm sure that's true for Vista and 7). Another thing is that when your user wants to check, what you store, he can also check registry. It's not hidden from users. I would recommend (as people answered here) encrypting your XML configuration and store it somewhere in user profile directory. This way checking what you store will be difficult (but not impossible).
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
Btw, you probably know this, but you can't really keep anything from the user. Normal users aren't going to mess around with the registry or even XML files. Users like me will still mess around with encrypted data, and you can't do anything about it, the way to decrypt it will be in the application.
|
|
|
|
|
harold aptroot wrote: Normal users aren't going to mess around with the registry or even XML files.
You right. I seem to proccess the end user's mind set through my own curiosity driven brain. 
I store my XML file within the CommonAppDataPath folder which is buried deep inside the drive's root directory. This should be hidden enough for a normal user.
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
Most people don't even know that such a place exists
|
|
|
|
|
I've recently tried implementing single sign-on using a desktop application and gmail. I failed after numerous attempts. So I've got another question to ask before I go on a wild search on the Internet again. Do you think it would be possible to link a Gmail account with MS Outlook, and then integrate Outlook into a desktop C# application and access the Gmail account like that? Or maybe even using some other provider such as Hotmail? I need to have some sort of single sign on up and running using a desktop application soon and I'm quickly starting to run out of ideas 
|
|
|
|
|
Greetings,
Somehow the lenght of my file stream is 0.
Anyone could point me out why, please?
string path;
StringBuilder sb = new StringBuilder();
char c;
char[] temp = new char[10];
Boolean munching = true;
if (txtFilePath.Text != "" && txtFilePath.Text != null)
{
path = txtFilePath.Text;
if (File.Exists(path))
{
FileStream fs = new FileStream(@"C:\test.pdf", FileMode.Open);
BinaryReader br = new BinaryReader(fs);
while (munching == true)
{
br.Read(temp, 0, 10);
c = temp[0];
}
}
else
{
}
}
else
{
}
|
|
|
|
|
Bazewouelle wrote: Somehow the lenght of my file stream is 0.
What is the content of path and the length of C:\test.pdf?
It's time for a new signature.
|
|
|
|
|
Somehow, the pdf had reset to 0 bytes... (?)
thanks again,
|
|
|
|
|
I see strange things:
1.
you have a something (probably a TextBox) that holds a path, yet you do not use its content. Instead you open a fixed file.
2.
If txtFilePath really is a TextBox, no need to test for Text==null as TextBox.Text never holds null, it always holds a real string ("" if no data is present).
3.
your while loop is bizarre.
4.
what makes you think the FileStream has length zero? there is nothing in the code to indicate that.
BTW: as you have been trying to extract text from a PDF file, which isn't necessarily all text, the whole approach is wrong. You should read the entire file as binary bytes, why not use File.ReadAllBytes()?
|
|
|
|
|
thanks Luc, this helps too
|
|
|
|
|
If fs.length is 0, then there's nothing in your file.
And I want to point out something Luc said. Your while loop is an infinite loop. You never change munching, so munching will always be true.
Also, while we're talking about it...you don't need to test a boolean against a value within a while loop. You're simply adding an extra test that is unnecessary.
while (munching)
is the same as
while (munching == true)
and uses one less evaluation. If you want to test against false, you would write
while (!munching)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
