|
Yes, MSDN says so but there is a workaround..
Read this[^].
|
|
|
|
|
Is there anything wrong with just running a normal Windows application?
But really, try to think about it. You start as a service, this happens before login, so where exactly is your UI suppose to go? See, it doesnt make sense. Rather start the app from start up.
All that said, here is probably the better idea:
1. Create a service.
2. Create a Windows Forms application, and add to start up folder or registry.
3. Use remoting to so the Winforms app can communicate with the service if necessary. BTW, you say you just wanna stop a service, so remoting will not even be needed (but somehow it seems you want to stop the service from within the service, not sure how that will work).
|
|
|
|
|
leppie wrote: But really, try to think about it. You start as a service, this happens before login, so where exactly is your UI suppose to go? See, it doesnt make sense. Rather start the app from start up.
All that said, here is probably the better idea:
1. Create a service.
2. Create a Windows Forms application, and add to start up folder or registry.
3. Use remoting to so the Winforms app can communicate with the service if necessary. BTW, you say you just wanna stop a service, so remoting will not even be needed (but somehow it seems you want to stop the service from within the service, not sure how that will work).
Thanks for the alternate choices.
But my service calls a console application and in this I perform background operations, like collecting system information.
I dont need that user must have UI at startup.
The service will start and call the console app. I have created a tray icon for the console app and whenever the user wants to shut down the console app, he right clicks the tray icon and stops it. The service dosent stop as such.
This is because the service launches the console app after some regular intervals of time to collect information data again.
Now you must have understood why I cant put it (the console app) in startup folder. That is because the app needs to collect information periodically which can only be scheduled by the service.
And if the service dosent interact with the desktop then the tray icon wont be visible.
Now have you got any suggestions?
Any help would be gratly appreciated.
Thanks !
modified on Tuesday, May 27, 2008 5:53 AM
|
|
|
|
|
Again, can a Windows Forms app not launch the console application? It can, and you can even run it (the console app) in the background without a shell window.
|
|
|
|
|
|
|
Hello Friends I have a main form in which there is a file menu strip. What I want to do is that when ever I click a menu strip of that menu a new for will be shown and all the menu strip will be disabled. And After I close the new form all the menu strips of the main form will be available again. What Can I write in form Closed method of the 2nd form? Can any one help me?
|
|
|
|
|
You can do like this..
ON MDI Form
public bool MenuItemControl
{
set
{
this.newToolStripMenuItem.Enabled = value;
}
}
ON FORM CLOSED EVENT
MDIParentForm MdiPF = (MDIParentForm)this.MdiParent;
|
|
|
|
|
|
Is there any key/value pair type class which can return "Key" object from "Value" ? I have done this by inheriting from generic Dictionary class. It works pretty well now. But I need to know if there is any predefined classes available. Any ideas ?
|
|
|
|
|
So you want to get values based on keys AND keys based on values?
|
|
|
|
|
Yes. And my collection will have only unique values.
|
|
|
|
|
This is what I have done.
public bool TryGetCategory(string value, out string category)
{
category = null;
if (this.ContainsValue(value))
{
foreach (KeyValuePair<string, string> pair in this)
{
if (pair.Value == value)
{
category = pair.Key;
return true;
}
}
}
return false;
}
This method is in a class which inherits from Dictionary<string,string>
|
|
|
|
|
DictionaryEntry class can be used to get key from value.
|
|
|
|
|
d@nish wrote: DictionaryEntry class
It's a structure, not a class. It's same like key/value pair and it is not a collection.
|
|
|
|
|
N a v a n e e t h wrote: It's a structure, not a class
Oh yes.Sorry.
|
|
|
|
|
There is method GetKeyForItem in KeyedCollectionClass. Is that what you are looking for?
|
|
|
|
|
d@nish wrote: There is method GetKeyForItem in KeyedCollectionClass
Thnaks. But it's an abstract class and I should override the GetKeyForItem method.
|
|
|
|
|
To make that efficiently (without looping through the items in the collection), you need to keep another dictionary where you switch the key and value.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Great. Do you mean putting another dictionary instance which is not visible to outside of class. When new items are added/removed from the main dictionary, this internal one also should synchronize. Right ?
|
|
|
|
|
Yes, that will be the best.
|
|
|
|
|
Thanks. How about the performance if collection is big ?
|
|
|
|
|
N a v a n e e t h wrote: Do you mean putting another dictionary instance which is not visible to outside of class.
Basically, yes. If you want to access items both on key and value, I suggest that you make a class that encapsulates two dictionaries, and only expose methods for adding, removing and do key and value lookups.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Okay. Thanks for that. Will it be an performance overhead if collection is big ?
|
|
|
|
|
N a v a n e e t h wrote: Will it be an performance overhead if collection is big ?
There will be some memory overhead, as a dictionary uses about 20 bytes to keep track of each entry.
Accessing items by key is a O(1) operation, so the size of the dictionary doesn't affect the time to fetch an item (assuming of course that the type of the key doesn't have a lousy algorithm for producing hash values).
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|