R. Erasmus wrote:
I agree with GuyThiebaut that you won't have advantages of debugging... thus would suggest sanity checks throughout your script (a good practice even if you're writing a compiled app).
Not ok... even scripts should get a complete test set. Especially as it is going to be important in production. Don't cut corners there, you'll regret it.
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
Your main question is related to maintainability of the solution imo. Who is going to maintain it? What technology (script language) do you intend to use? Who else can handle this technology in your team? What is your rollout strategy like? Do you require formal testing and signoff for example... Just to name a few... For me; scripts are easier to roll out than executables. And .NET is not a data friendly solution if all you need is CSV formats to be handled.
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
Goto is a perfectly well usable statement. It's been considered a bad practice from the times people tended to write spaghetti code by using only goto for flow control in their code. It is a tool, and if you use it right, it will help you write simple and maintainable code. But as with any tool, if you use it in a bad way, you get what you deserve. If I have nested code, if-then, several levels deep, I prefer goto. Much cleaner. Writing a function that throws the same exception in 10 places (example elsewhere in this discussion, with the critique he should have used exceptions) is more complex than the provided sample with the gotos (which I like). Could have done it myself. As a note; Lua 5.2 (released 2012) got the goto statement as a new enhancement to the language (so after 20 years of Lua)
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
Couldn't agree more. A bad coder will write bad code in C# or any other language as well. It's the coder that makes the difference, not the language. fwiw; I like VB over C#, I hate all the curly braces. Especially when maintaining someoneelses code. I find it far easier to read VB code.
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
Time to debug .Net stuff went down drastically
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
Lately I notice that my coding has improved dramatically on the first-time-right element. For the past 12 months I've been coding mostly Lua and some javascript, both dynamic languages. Before it was mostly static, .Net et al. I'm really amazed about the small number of errors in my code lately, even when being back at .Net stuff. My guess is that the static languages turned my brain lazy, where now the dynamic language forces it to stay alert which really improves the quality. anyone else experiencing the same?
I'm using VMware, running a base Win7 Pro 32bit, with a Win7 64bit VM on top of that.
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
Have you tried it? Or can you be more specific? A string in .NET is not just a list of bytes. Every character consists of 1 or more bytes depending on the encoding used. The method provided will read the file into a proper encoded string. All you have to do is traverse the string and count the characters.
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
For my 2cts; I don't think there is any way to detect the codepage, you ought to know it before opening it. Text files don't have any metadata to tell you anything about its content. So if you know the encoding, you can load the full file by using System.IO.File.ReadAllText(path As String, encoding As Encoding) As String. From here you should have a properly encoded string and you can start counting characters.
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
Meanwhile I ran some tests and my conclusion is that I cannot use the BackgroundWorker. Thing is with the BackgroundWorker, that the described behaviour is only valid in a windows forms application. If you run it in a forms application, the ProgressChanged handler indeed runs on the creator thread (the UI thread), but if you use it in a console application, the ProgressChanged handler runs on the DoWork background thread.
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
Thx for your time. I get your point, but... that would make my library capable of only raising the standard ProgressChanged and RunWorkerCompleted events, and not the custom events used in my library. Is there any description on how the BackgroundWorker class does its magic? that would allow me to re-create it and add my own events
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
I am working on a library that uses multiple threads to do all kinds of work. The work being done results in events being generated. Preferably I would like all communications to the outside world to be on a single thread, so most threading issues can be dealt with inside the library. When using forms there are the standard components with the Invoke methods that let the thread that runs the form call the requested Delegate, so whatever needs to be done (raise an event in my case) gets executed on that form thread. Is there a way to do this generically, without forms or components? Say I have 1 main thread that spawns 10 or 20 worker threads. And whenever the workers have an event to raise, they let the main thread do this? Is there an easy way (that I just haven't found), or should I be creating some custom threadpool management code to achieve this? Any thoughts?
If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
I think the best way would be using a waithandle that signals when done. If you combine the waithandles for all processes, you can use the WaitHandle.WaitAll Method. See this MSDN article for an example