|
I believe this has to be done through custom actions. This[^] MSDN page has got some details on creating a custom action.
Best wishes,
Navaneeth
|
|
|
|
|
Please do not cross post your question.
Once you posted it, it will already get
noticed.
You have already posted your query here[^].
HTH
Jinal Desai - LIVE
Experience is mother of sage....
|
|
|
|
|
Hi all,
I want to globalize and localize my Win Form Application.
I have read many article and gone through many ways of doing.
Mainly,
1. For Forms, through property window of the form, set the Language property e.g to French and for all the controls present on the form set Name property specific to each culture. It will automatically create the .resx file for each language.
2. Manually creating the .resx file and using ResourceManager.GetString, set the text of each control on the form.
I understand how to do it in the same project.
But in my application I have many modules. Every module have many forms, images and error messages.
I want to move all these resources and the translated strings to some Central Resources Dll.
All the other Modules( dlls or Exe) will access it depending on the Language selected.
Please let me know what is the best way to so it.
Thanks in advance.
|
|
|
|
|
|
|
IMO both could work well, you should choose what suits you most. I would go for threads if the job may take long, has lots of state, or is rather complex; and for a timer when it is rather simple, short, lightweight.
|
|
|
|
|
Luc, thanks for your answer. What do you mean by "has lots of state"?
|
|
|
|
|
Sorry, should have been lots of states or state variables, and is actually only relevant if you have to restore the object from one timer tick to the next, it probably does not apply to what you are trying. It is most relevant when a job is going to be sliced in smaller jobs that may be handled by a number of consecutive timer ticks.
|
|
|
|
|
I generally use a System.Timers.Timer -- they work for me.
An additional benefit (to me anyway) is that the handler method enters and exits on each cycle rather than running indefinitely. In my opinion, the method shouldn't need to know that it is implementing a periodic function. Using a Timer allows me to separate responsibilities.
The downside is that if the code takes longer to execute than the timer's interval, you wind up with two executions running at the same time -- you would need to allow for that or prevent it.
|
|
|
|
|
Would this be a correct approach to prevent more than one execution:
protected override void OnStart(string[] args)
{
WriteEventEntry("TestService starting...", EventLogEntryType.Information, 100, 100);
timer.Elapsed += new ElapsedEventHandler(timer_Tick);
timer.Interval = 5000;
timer.Enabled = true;
}
private void timer_Tick(object sender, EventArgs e)
{
timer.Enabled = false;
WriteEventEntry(DateTime.Now.ToString() + " timer ticked...", EventLogEntryType.Information, 100, 100);
timer.Enabled = true;
}
?
|
|
|
|
|
Yes, but I suggest you use a try/catch/finally with the timer.Enabled = true; in the finally. (Unless you want your Service to stop when it encounters an Exception.)
|
|
|
|
|
I mostly use threads, and if you want to keep the periodicity logic apart from the rest of the logic you can use something similar to this:
while(true)
{
DoStuff();
sleep(1000);
}
The good thing about this, is that you running this code through a separate thread; thus it does not interfere with the UI thread. On large processes this will save you a lot of problems with the application not responding or working slower than expected.
Anyway as someone else told you both solutions could work, I'd use timer for trivial tasks and the thread worker for more complex stuff, but that's just my choice.
|
|
|
|
|
Hmm ... windows services don't have a UI thread 
|
|
|
|
|
Touche!!
And that's why my mamma told me I need to read the question before giving an answer :$
|
|
|
|
|
I use a timer, it just seems neater.
|
|
|
|
|
JoeSchmoe007 wrote: Is there any reason to prefer worker thread approach?
It depends on what you are trying to do. Timer is used when you want to get the callback in periodic intervals. One thing to note is, timer will fire the callback even if the previous call is in progress. All it does is queuing the job to a thread pool thread.
If you don't have something to execute periodically, spawn a thread or use one from thread pool. I have seen people simulating the timer's behavior by spawning worker threads and sleeping on it, which is of course a bad design.
There is no difference internally because both are using separate thread to do the job.
Best wishes,
Navaneeth
|
|
|
|
|
Can you elaborate why sleeping on the worker thread is bad design? I see this approach used often. What design would you recommend instead when worker thread is used?
|
|
|
|
|
JoeSchmoe007 wrote: Can you elaborate why sleeping on the worker thread is bad design?
Because Thread.Sleep may or may not sleep for more time than you specified. Take a look at this[^] article.
IMO, the decision to use sleep is also subjective. If you need accuracy on the intervals, you should not use Thread.Sleep. If you are waitting for some condition to happen, say wait for an external device to be up, you should use WaitHandle instead of Thread.Sleep. Consider the following example:
A windows service which is expected to do some job at every 10 minutes accurately (Eg: downloading a webpage and indexing the contents). You start the service and 12.00 and it should run at 12.10, 12.20 and so on. Unfortunatly the work took 15 minutes to complete. Now the program won't run at 12.20 instead it will run at 12.35. You loose the accuracy!
This is where timers are useful.
JoeSchmoe007 wrote: What design would you recommend instead
A windows service is something which is active all the time. If your application is doing the work only at specific intervals then it is not a good candidate for a service. It'd be better to create it as a normal console application and schedule it using the operating system's scheduler.
Best wishes,
Navaneeth
|
|
|
|
|
I am trying to communicate with linux machine. The documentation on the server running in the linux machine tells met the following-- "The proctocl shall be synchronous. The system will not send a command over the same TCP connection until it has recieved a reply to the first command....."
From the above I am asumming, I should use synchronous communication to talk to the server on the linux machine. Is that accurate? I am not receving the correct replies to my synchronous communication. Is there any chance that it could be asynchronous?
Thanks
Jobin THomas<code></code>
-- Modified Tuesday, July 27, 2010 11:31 AM
|
|
|
|
|
This question is impossible to answer since we do not have the documentation that you are referring to. When you say that you are not receiving the correct replies it may be that you are not sending the correct requests; again only the documentation or the source code could help you to resolve it. Since it is Linux, and thus open source, you should have access to both.
It's time for a new signature.
|
|
|
|
|
You should be able to use either -- I'd use asynchronous.
|
|
|
|
|
Thanks for the help. The issue was the stupid linux machine wasnt listening to my I.P address. We had to add some script to make it listen to my I.P. Synchronous communication works pretty good.
Thanks for the help.
|
|
|
|
|
When Windows Service application is created by VS 2008 via "Windows Service" template it is created as Windows application ( /target:winexe)
For convenience of debugging I modified it so that it can be started both from the command line and as a service using this approach:
static void Main(string[] args)
{
ServiceBase[] ServicesToRun;
TestService srv = new TestService();
ServicesToRun = new ServiceBase[]
{
srv
};
if (Environment.UserInteractive)
{
char KeyChar;
srv.ManualStart(args);
Console.WriteLine("Service started in console mode, press Space key to stop");
Console.WriteLine("Press any letter or digit to send control command (ASCII code +128)");
while (true)
{
KeyChar = Console.ReadKey().KeyChar;
Console.WriteLine("");
if (KeyChar == ' ')
break;
else
{
srv.ManualCustomCommand(KeyChar + 128);
}
}
srv.ManualStop();
}
else
ServiceBase.Run(ServicesToRun);
}
In order for this to work as expected I had to change output type from "Windows Application" to "Console Application" ( /target:exe). Everything currently works the way I expect.
Is this acceptable for Windows Service to be compiled as Console application? Are there any implications? Should I have kept it as "Windows Application" and attached console to it using approach described here: http://www.csharp411.com/console-output-from-winforms-application/ ?
|
|
|
|
|
I would arrange all the stuff that you want to run as the service into another class project. Then you can have the Windows Service project reference to this project for actual usage, and create console app project or windows app project that reference the class project for debugging.
|
|
|
|
|
Windows Services have no GUI so Winexe makes no sense. I always compile service programs as console, but more to the point, I compile the actual service code in a DLL which the program calls.
I do pretty much what you show there and control my services from the command line.
Edit: When I write an application that can be used in console or WinForms mode, I compile it as console.
modified on Monday, July 26, 2010 1:21 PM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
